142-Manual VPN

Resumen Ejecutivo
Misión
Linux Latin América es la empresa pionera y líder en servicios globales de TI basados en
plataforma Linux y software libre. Proveemos servicios de capacitación, consultoría, soluciones,
soporte técnico e integración de productos innovadores y de primer nivel en base a Sistema Operativo
LINUX para asegurar, resguardar y rentabilizar los procesos tecnológicos de grandes y medianas
organizaciones, quienes nos premian con relaciones de largo plazo.
Visión
Linux Latin América será el proveedor latinoamericano líder de servicios globales de TI en
plataforma Linux. Tecnología que será altamente demandada por los gobiernos y principales empresas
de la región. Para lograrlo, nos concentraremos en elevados niveles de calidad, innovación y
especialización de nuestros profesionales.
Principios que nos inspiran
- Enfoque al cliente
- Liderazgo Especializado
- Participación del personal
- Mejora Continua
- Relaciones Beneficiosas con el proveedor
- Responsabilidad Social
Presentación Corporativa Linux Latin América 2008

Su política de Calidad
Linux Latin America logra la s atisfacción de sus clientes a traves de la entrega de servicios de
soporte e ingeniería en forma efectiva, ajustando a los requerimientos, buscando estar de acuerdo a
su misión y visión y atendiendo a nuestro compromiso permanente de mejora continua.
Sus objetivos de Calidad

- Lograr que el indicador satisfacción de sus clientes tenga un valor igual o superior a
los planificados por la alta gerencia.
- Que sus técnicos y profesionales tengan una evaluación, por parte de sus clientes,igual
o superior a lo planificado por la alta gerencia.
- Cumplir satisfactoriamente los tiempos estipulados.
- Que sus ejecutivos comerciales tengan una evaluación por parte de sus clientes igual
o superior a la estipulada por la alta gerencia.

¿Qué servicios ofrecemos?
Consultoría
Los proyectos de migración realizados por Linux Latin America están basados en un análisis previo
del impacto de la migración y una planificación detallada de cada una de las fases.
Dada la envergadura y diseño de estos proyectos, es que se encuentran integrados con diferentes
y múltiples servicios que en su totalidad permiten conseguir una implantación final satisfactoria.
Levantamiento y Detalle de Requerimientos - Fase Inicial de Asesoría

Diseño e Implementación de la solución - Fase de Ejecución
Capacitación de S.O. Linux - Fase Capacitación
Soporte y Asistencia Técnica - Fase Soporte y Asistencia
Estudios de viabilidad técnica y económica •'95 Planes de Migración •'95 Pilotos y Prototipos

Implementación de Soluciones Opensource
- Mensajería. - Servidores de Correo con herramientas de colaboración - Agenda
Compartida Webmail - Mensajería Instantánea Encriptada - Foros de Discusión -
Libreta de Direcciones Corporativa.
- Soluciones de Telefonía y Voz sobre IP con Asterisk.
- Servidores de Archivos - Controladores de Dominio (Samba / OpenLDAP) - Single

Sign - On.
- Seguridad. Firewall - VPNs - Detector de Intrusos - Análisis Forense - Proxy -

Filtros de Internet.
- Herramientas de Monitoreo de Servidores y Red. Nagios - Cacti - MRTG - Ethereal

- NTOP.
- Mon - Tunning para servidores de bases de datos Oracle y Sybase.
- Clusterización de Servidores : Alta Disponibilidad - Balanceo de Carga - Oracle RAC.
Implementación de Soluciones Comerciales para Linux

Novell Groupwise® - Novell e-Directory® - Oracle - RedHat Cluster Suite - RedHat GFS -
Solución Corporativa Retail Novell Linux Point-of-Sales.
Soporte y Asistencia Técnica

Asistencia Telefónica - Presencial en dependencias del cliente - Acceso remoto seguro -
Asistencia vía e-mail.
Capacitación y Certificación
Contamos con una amplia gama de cursos en plataformas Linux y Software libre, con salas
totalmente equipadas para realizar una capacitación práctica e interactiva. Todos nuestros cursos
cuentan con Franquicia Sence.
Por otro lado el reconocimiento que Red Hat nos ha entregado por ser el único centro de
capacitación en Chile que puede entregar los cursos de certificación (RHCE-RHCT), nos sitúan como
principal proveedor de capacitación y consultorías relativas al software libre en Chile y Latinoamérica.

¿Por qué elegir Linux Latin América?
- Dado su concentrado foco de negocios, somos sólo especialistas en ofrecer soluciones
de infraestructura basadas en plataforma linux y herramientas de software libre.
- Es la empresa chilena con más experiencia en soluciones linux en el mercado nacional.
Es la que posee el mayor número de ingenieros certificados RHCE (Certified Engineer)

y RHCX (Certified Examiner). Business Partner RedHat (http://www.redhat.com).
- Cuenta con la base de servidores linux instalados más amplia en el sector corporativo.
- Para ofrecer los más altos estándares de calidad, Linux Latin America se encuentra
certificada ISO9001/2000.
- La solidez de nuestras alianzas con los más importantes fabricantes de tecnología y otras
empresas especializadas, nos permiten abordar todo tipo de proyectos.
http://www.linuxlatinamerica.com
Argentina:
Victoria Ocampo Nº 360, 3º Piso - Puerto Madero - Buenos Aires.
Tel: +54 (11) 45156332.
Chile:
Mariano Sánchez Fontecilla # 310, 2do Piso - Edificio Birmann 24 Las Condes - Santiago
Tél : +56 2 4834000 - Fax : +56 2 4834050 - Call Center Soporte 600 4834100
Mexico:
Insurgentes Sur Nº 2384 Col. Chimalistac. Deleg. Álvaro Obregón. Mexico D.F.
Tél: +52 55 53507487.
servicioalcliente@linuxlatinamerica.com

Sea libre, use Linux.
Sistemas Operativos
Linux Básico LC ADM 101
Los participantes aprenderán los conceptos de Linux, este curso esta dirigido a usuarios que desean usar Linux en sus actividades diarias.
Duración: 12 Hrs
Administración Linux -LC ADM 100

Proporciona al participante los conocimientos y procedimientos para administrar un servidor Linux y servicios de red asociados, como
administración, correo, web, servicio de archivo, DNS, FTP.
Duración: 40 hrs.
Resolución de problemas- LC ADM 200

Proporciona al participante los conocimientos y procedimientos para la administración avanzada de un servidor Linux, incluyendo los
tópicos de red y ruteo, lista de control de acceso, respaldos y recuperación, programación de Scripts, SSH y resolución de problemas.
Duración: 24 hrs.
Seguridad Linux – LC SEG 200

El participante sera capaz de dominar la operación, configuración de Linux con las características necesarias para mantener actualizado
y seguro un servidor proxy, router y/o firewall Linux
Duración: 36 hrs.
Infraestructura – LC INF 300

Los participantes podrán diseñar, implementar los servicios de infraestructura sobre Linux
Duración: 36 Hrs
Aplicaciones
Samba – Ldap - Postfix
Este curso esta orientado a la centralización de autentificación de servicios de la red corporativa
Duración: 24 Horas
Monitoreo de Red – LC SEG 201

El participante podrá monitorear el estado de la red (tráficos de paquetes, estado de servicios, utilización ancho de banda).
Duración: 24 horas.
VPN- LC SEG 200

VPN El participante será capaz de crear redes primarias virtuales, es decir, interconectar dos redes remotas a través de un túnel seguro.
Duración: 24 hrs
Cluster- LC CLU 300

El participante logrará realizar el balanceo de carga y alta disponibilidad de servicios de Red.
Duración 12 hrs.
Asterisk - LC AST 300

El participante logrará integrar plantas telefónicas análogas y digitales, PABXS virtuales, Routers de llamada, discadores automáticos
IVR, tarificación todo implementado con tecnología open Source
Asterisk Duración: 40 hrs.
Ofimática
Open office – LC ADM 102
OpenOffice.org Proporciona a los participantes un manejo básico de los conceptos prácticos, teóricos, fundamentales para la utilización de esta suite
ofimática compuesta por: procesador de texto, planilla de calculo y base de dato.
Duración: 24 horas
www.linuxlatinamerica.com
Desarrollo
UML- LC UML 100
El participante conocerá los conceptos propios del modelo orientado al objeto, también aplicará las diversas técnicas del análisis y diseño
orientado a objeto. Construir la especificación de un sistema utilizando objetos.
Duración: 24 hrs.
XML- lC XML 100

XML El objetivo es familiarizar al participante con el uso XML en Internet, se mostrara como escribir documentos XML , como presentarlas
usando hojas de estilo o aplicándole transformaciones.
Duración: 36 hrs.
Java – LC JAV 200

Prepara al participante en técnicas y herramientas de programación JAVA
Duración: 30 hrs.
J2EE – LC J2E 400

Proporciona toda la información necesaria para crear aplicaciones basadas en el estándar J2EE, adoptado globalmente por las grandes
empresas como plataformas de desarrollo.
Duracion: 40 hrs.
Desarrollo
PHP – LC PHP 100
Este curso entrega los conocimientos necesarios para crear paginas web dinámicas. A través del uso de PHP el cual permite el acceso a
múltiples repositorios de datos.
Duración: 30 hrs.
PHP MYSQL – LC PHP 200

Comprender los fundamentos de MYSQL y el acceso a este motor de base de datos a través de PHP
Duración: 30 hrs.
PHP POSTGRE SQL – LC PHP 201

Los participantes lograran conocer, administrar e implementar Postgre SQL en la empresa. Así como programar en los principales
lenguajes para desarrollar aplicaciones estables.
Duración 30 horas
Perl – LC PER 100

El participante dominará el uso del lenguaje para generar reportes a través de la conexión a una base de datos o el procesamiento de
archivos(expresiones regulares).
Duración: 25 hrs.
Base de datos
Mysql (Intermedio y Avanzado)
Aprender a Manejar, Administrar y migrar base de datos a MySQL
Duración: 30 Hrs.
Administración de PostgreSQL (Intermedio y Avanzado)

Prepara al alumno para administrar sistemas con PostgreSQL y depurar los errores posibles frente a fallas del sistema.
Duración: 30 hrs
Certificaciones
Red Hat: Novell - Suse:
Introducción a Redhat Linux (RH033) - Administración del Fundamental de SUSE LINUX (curso 3071) - administracion de
sistema Red Hat Linux y examen RHCT (RH133) - Red Hat Linux Suse Linux (Curso 3072) - Administración avanzada Suse
Networking y seguridad (RH253) - Rapid Track (RH-300). Linux (3073) - Examen profesional del practicum de la certificación
(Novell CLP)
CHILE ARGENTINA MEXICO

Mariano Sánchez Fontecilla 310, Victoria Ocampo N° 360, 3° piso Insurgentes Sur N° 2384 Col. Chimalistac
Edificio Birmann - 2° piso C1107BGA - Puerto Madero - Buenos Aires Delg. Álvaro Obregón - C.P 01070. Mexico, D.F.
CP7550515 - Las Condes - Santiago Tel: +54 (11) 45156332 Tel: +52 (55) 53507487 / +52 (55) 53507496.
Tel: +56 2 483 4000 - Fax: +56 2 4834050
w w w . l i n u x l a t i n a m e r i c a . c o m

!"

#
$ %&

# &

!
" # $
%

#

%
&

%#

&

' & '

(
" )
*

" , -.

# "
/
(
0
!

'
(
"
!
" #$

(")

#

'
(
" "
), 1
)"$ '

(
"

*$+,$*+
-")

&
"
),

#
2 3 # 4 #

."$

'$"
/" $ '

(
"

*,

$

6

6

&

6

4
#
.

6

'

#

$ '
(
"

#7

89

(

*

*

(

#7

,*+
0")

:; )#!;8<98=
1" $

#

2"1

#

:9 -3 # #
>9 -3
&

?-3 4
1

#

>9-3

(

!3;$

@

@

@

% *>A*
@'

!!")
:=

8AAB

!(" $

&

C ,

,

#
4
5 67
!)" )

#
*

!-")
*
?9B
!." $ '

(
"

4

*
8>;#8:;

Índice de contenido
UNIDAD 1.................................................................................................................................................3
¿Qué es una VPN?......................................................................................................................................5
Ventajas de una VPN..................................................................................................................................6
Tecnologías para armar VPNs: ..................................................................................................................7
Tipos de VPNs:..........................................................................................................................................9
Tunneling.................................................................................................................................................10
UNIDAD 2................................................................................................................................................11
INTRODUCCION....................................................................................................................................12
Como trabaja GPG....................................................................................................................................13
Firmas Digitales.......................................................................................................................................13
Tipos de Encriptacion...............................................................................................................................13
Ejemplo de Uso GPG:..............................................................................................................................14
UNIDAD 3...............................................................................................................................................18
Qué és PPTP.............................................................................................................................................19
Qué és PoPToP.........................................................................................................................................19
Requerimientos del sistema......................................................................................................................19
Implementacion de cliente y servidor ......................................................................................................21
/etc/pptpd.conf .........................................................................................................................................23
/etc/ppp/options.pptp................................................................................................................................24
/etc/ppp/chapsecrets ...............................................................................................................................24
UNIDAD 4...............................................................................................................................................26
INTRODUCCION:...................................................................................................................................27
Instalación de IPsec..................................................................................................................................29
Configuración IPsec de hostahost..........................................................................................................30
Configuración de IPsec de redared........................................................................................................37
UNIDAD 5...............................................................................................................................................43
INTRODUCCION SSH / OpenSSH........................................................................................................44
Portforwarding........................................................................................................................................44
Forwarding de X.......................................................................................................................................46
SSH sin password.....................................................................................................................................48
VPN REDES PRIVADAS VIRTUALES 11
UNIDAD 1
FUNDAMENTOS VPNs
¿Qué es una VPN?
La VPN es una tecnología de red que permite una extensión de la red local sobre una red
pública o no controlada, como por ejemplo Internet.
El ejemplo más común es la posibilidad de conectar dos o más sucursales de una empresa
utilizando como vínculo Internet, permitir a los miembros del equipo de soporte técnico la
conexión desde su casa al centro de cómputo, o que un usuario pueda acceder a su equipo
doméstico desde un sitio remoto, como por ejemplo un hotel. Todo esto utilizando la
infraestructura de Internet.
Las Redes Privadas Virtuales utilizan tecnología de túnel (tunneling) para la transmisión de
datos mediante un proceso de encapsulación y en su defecto de encriptación, esto es
importante a la hora de diferenciar Redes Privadas Virtuales y Redes Privadas, ya que esta
ultima utiliza líneas telefónicas dedicadas para formar la red.
Para hacerlo posible de manera segura es necesario proveer los medios para garantizar la
autenticación, integridad y confidencialidad de toda la comunicación:
• Autenticación y autorización: ¿Quién está del otro lado? Usuario/equipo y qué nivel
de acceso debe tener.
• Integridad: La garantía de que los datos enviados no han sido alterados.
• Confidencialidad: Dado que los datos viajan a través de un medio potencialmente
hostil como Internet, los mismos son susceptibles de interceptación, por lo que es
fundamental el cifrado de los mismos. De este modo, la información no debe poder ser
interpretada por nadie más que los destinatarios de la misma.
Ventajas de una VPN
• Seguridad: provee encriptación y Encapsulación de datos de manera que hace que
estos viajen codificados y a través de un túnel.
• Mejor administración: cada usuario que se conecta puede tener un numero de IP fijo
asignado por el administrador.
• Facilidad para los usuarios con poca experiencia para conectarse a grandes redes
corporativas transfiriendo sus datos de forma segura.
• Costos: ahorran grandes sumas de dinero en líneas dedicadas o enlaces físicos.
La principal motivación del uso y difusión de esta tecnología es la reducción de los costos
de comunicaciones directos, tanto en líneas dialup como en vínculos WAN dedicados.
Los costos se reducen drásticamente en estos casos:
En el caso de accesos remotos, llamadas locales a los ISP (Internet Service
Provider) en vez de llamadas de larga distancia a los servidores de acceso remoto de
la organización. O también mediante servicios de banda ancha.
En el caso de conexiones punto a punto, utilizando servicios de banda ancha para
acceder a Internet, y desde Internet llegar al servidor VPN de la organización. Todo
esto a un costo sensiblemente inferior al de los vínculos WAN dedicados
Tecnologías para armar VPNs:
Todas las opciones disponibles en la actualidad caen en tres categorías básicas:
• Las soluciones basadas en hardware.
• soluciones basadas en cortafuegos.
• Soluciones basadas en software.
El protocolo estándar de hecho es el IPSEC, pero también tenemos PPTP, L2F, L2TP,
SSL/TLS, SSH, etc. Cada uno con sus ventajas y desventajas en cuanto a seguridad,
facilidad, mantenimiento y tipos de clientes soportados.
Actualmente hay una línea de productos en crecimiento relacionada con el protocolo
SSL/TLS, que intenta hacer más amigable la configuración y operación de estas soluciones.
• Las soluciones de hardware:
casi siempre ofrecen mayor rendimiento y facilidad de configuración, aunque no tienen
la flexibilidad de las versiones por software. Dentro de esta familia tenemos a los
productos de Nortel, Cisco, Linksys, Netscreen, Symantec, Nokia, US Robotics, Dlink
etc.
• En el caso basado en cortafuegos:
se obtiene un nivel de seguridad alto por la protección que brinda el cortafuegos, pero
se pierde en rendimiento. Muchas veces se ofrece hardware adicional para procesar la
carga RPV. Por ejemplo: Checkpoint NG, Cisco Pix.
• Las aplicaciones RPV por software:
son las más configurables y son ideales cuando surgen problemas de
interoperatividad en los modelos anteriores. Obviamente el rendimiento es menor y la
configuración más delicada, porque se suma el sistema operativo y la seguridad del
equipo en general. Aquí tenemos por ejemplo a las soluciones nativas de Windows,
Linux y los Unix en general.
Por ejemplo productos de código abierto (Open Source) como OpenSSH, OpenVPN y
FreeS/Wan
Tipos de VPNs:
Basicamente existen 2 tipos de arquitecturas VPNs:
1 VPN de (Acceso Remoto):
Un usuario remoto que solo necesita servicios o aplicaciones que corren en el mismo
servidor VPN o aplicaciones que se encuentran en uno o mas equipos dentro de la red
interna.
2 VPN (Punto a Punto):
Esta forma supone la posibilidad de unir dos intranets a través de dos enrutadores, el
servidor VPN en una de las intranets y el cliente VPN en la otra. Aquí entran en juego el
mantenimiento de tablas de ruteo y enmascaramiento.

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.
¿Qué es el tunneling? El problema de los protocolos que envían sus datos en claro, es
decir, sin encriptarlos, 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.
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.
UNIDAD 2
CRIPTOGRAFIA
INTRODUCCION
En la jerga de la criptografía, la información original que debe protegerse se denomina
texto en claro. El cifrado es el proceso de convertir el texto plano en un galimatías ilegible,
denominado texto cifrado o criptograma. Por lo general, la aplicación concreta del algoritmo
de cifrado (también llamado cifra) se basa en la existencia de una clave: información secreta
que adapta el algoritmo de cifrado para cada uso distinto.
Las dos técnicas más básicas de cifrado en la criptografía clásica son la sustitución
(que supone el cambio de significado de los elementos básicos del mensaje las letras, los
dígitos o los símbolos) y la trasposición (que supone una reordenación de las mismas); la
gran mayoría de las cifras clásicas son combinaciones de estas dos operaciones básicas.
El descifrado es el proceso inverso que recupera el texto plano a partir del criptograma
y la clave. El protocolo criptográfico especifica los detalles de cómo se utilizan los algoritmos
y las claves (y otras operaciones primitivas) para conseguir el efecto deseado. El conjunto
de protocolos, algoritmos de cifrado, procesos de gestión de claves y actuaciones de los
usuarios, en su globalidad es lo que constituyen un criptosistema, que es con lo que el
usuario final trabaja e interactúa.
Existen dos grandes grupos de cifras: los algoritmos que utilizan una única clave tanto
en el proceso de cifrado como en el de descifrado y los que utilizan una clave para cifrar
mensajes y una clave distinta para descifrarlos.
Los primeros se denominan cifras simétricas o de clave simétrica y son la base de los
algoritmos de cifrado clásico. Los segundos se denominan cifras asimétricas, de clave
asimétrica o de clave pública y clave privada y forman el núcleo de las técnicas de cifrado
modernas.
Como trabaja GPG
GPG (Gnu Privacy Guard, Guardian de Privacidad Gnu)
Alternativa a PGP (Pretty Good Privacy, Privacidad Bastante Buena).
Utiliza clave publica y privada.
Utiliza algoritmos no patentados.
ELGamal , CAST5, 3DES
Firmas Digitales
Se basa en la verificacion de la autoria de un mensaje
Reduce el riesgo de recir troyanos y scripts
Tipos de Encriptacion
Simetrico:
La llave para encriptar y desencriptar es la misma.
Asimetrico:
Se usan dos llaves una privada y una publica.
La diferencia con el simetrico es que si se usa la llave publica para encriptar y la privada para
desencriptar
Ejemplo de Uso GPG:
1 Creando mi clave(publica y privada)
[router]#gpg genkey
El Tipo de clave
puede ser DSA, ElGamal o ambos,
DSA solo se puede firmar digitalmente,
la recomendación es utilizar ElGamal o ambos,
ya que uno generalmente va a querer enviar datos encriptados.
El Tamaño de la clave
es importante, cuanto más grande, más dificil de crackear la clave, pero también una
clave más grande requiere mayor tiempo de procesamiento a la hora de encriptar y
desencriptar,
el valor por defecto (1024) esta bien para la mayoría de los casos.
La Cantidad de tiempo que dura la clave
es a consideración del usuario, uno podría pensar que lo mejor es que la clave no vensa
nunca,
así no tengo que tomarme el trabajo de acordarme de armar otra clave cuando esta vensa,
pero otros
piensan que dado que con el tiempo los sistemas de encripción son crackeados, lo mejor
es darle un tiempo
de vencimiento coherente para evitar un potencial crackeo3.1 de la clave.
Yo particularmente (aunque en el ejemplo use 1 año) soy de poner ``sin vencimiento'',
si alguien crackea mi clave en el futuro, ejecutaré el proceso de revocación y listo.
El Nombre Real
es simplemente el nombre del dueño de la clave
La Dirección de correo
este dato es sumamente importante y debe escribirse correctamente, especialmente si se
va a utilizar
programas que soporten gpg como Evolution o Kmail.
El Comentario
es algo que querramos agregar a la clave que sume para la correcta identificación del
dueño de la clave.
Finalmente nos pregunta si esta todo correcto y la frase que sella la clave que estamos
generando,
este frase es importante y se recomienda fuertemente que se utilize una frase (que
contenga espacios).
Por supuesto, esto no debe ser algo sumamente extenso, ya que esta frase la vamos a
tener que escribir una y
otra vez, en cada operación de encripción, descencripción y al firmar digitalmente algo.
Los archivos físicos
Cuando se genera un ``par de claves'' (acordate que una clave esta integrada por dos en
realidad,
la pública y la privada) terminan llendo a parar a archivos separados.
Todo esto se graba por defecto en el directorio .gnupg dentro del home directory del usuario.
La clave pública queda en el archivo /.gnupg/pubring.gpg y la clave privada en el archivo
/.gnupg/secring.gpg.
Estos archivos deben tener los permisos correspondientes,
los permisos clave privada debería tener 400 (solo lectura para el dueño)
clave pública 644 (lectura/escritura para el dueño y solo lectura para el resto).
2 Enviar la clave publica a quien quiero que me envie informacion
a) La envio por correo
b) En un disquete
Para la opcion a y b (exportamos la clave publica a un archivo)
[router]#gpg listsecretkeys
[router]#gpg listkeys (con esto veo los USERID de las claves)
[router]#gpg a export USERID > miclave.asc.pub
c) En un servidor de claves publicas
[router]#gpg sendkeys keyserver pgp.rediris.es <USERID>
3 Importar una CLAVE pub (ete proceso lo realiza quien recibe la llave)
a) Desde un archivo
[router]#gpg import miclave.asc.pub
b) Desde un servidor (sirve tambien para verificar su identidad)
[router]#gpg keyserver pgp.rediris.es recvkeys <USERID>
La salida del comando te debe dar algo parecido a esto:
gpg: key CA6E390E: "Fernando Mu±oz RioPÚrez ...@correo.es>" not
changed
4 Encriptado y Desencriptando información
Para encriptar y desencriptar información es necesario tener la clave pública de la persona a
la cual le enviaremos esta información encriptada.
El comando para encriptar: (la opcion armor permite que el archvio sea ascii en vs de binario)

gpg armor output salida.txt recipient 4A2C012C encrypt /etc/shadow

El comando para desencriptar:
gpg decrypt salida.txt

UNIDAD 3
POINT TO POINT TUNNELING PROTOCOL
Qué és PPTP
Diseñado como una extensión del PPP, PPTP encapsula paquetes PPP dentro de
datagramas IP para la transmisión a través de Int
ernet o otras redes públicas basadas en TCP/IP. Aunque nos duela decirlo, fue diseñado y
propuesto para ser estándar por Mic
rosoft en el año 1996, aunque también contribuyeron Ascend Communications, ECI
Telematics, 3Com/Primary Access y U.S.Robotic
s. PPTP puede ser usado para tunelizar los protocolos IP, IPX y NetBEUI.
Qué és PoPToP
Es la solución para servidores PPTP bajo GNU/Linux. PoPToP permite a
servidores linux funcionar correctamente en entornos PPTP VPN.
La versión actual soporta clientes PPTP Windows 95/98/NT/2000 y clientes
PPTP Linux. PoPToP es software libre GNU.
Requerimientos del sistema
Una distribución de GNU/Linux actual (RedHat, Debian, etc.) con un kernel reciente,
aunque funciona con kernels 2.0.x y 2.
2.x, recomiendo el uso de un kernel 2.4.x.
PPP 2.3.8 mínimo, aunque muchas distribuciones actuales ya llevan 2.4.x, y aparte
necesitaremos el parche para el ppp de M
SCHAPv2/MPPE si queremos autenticación y encriptación compatible con los clientes de
Micro$oft.
Parche MPPE para el kernel, soportados como ya he dicho anteriormente, 2.0.x, 2.2.x y
2.4.x.
– Servidor PPTP para GNU/Linux, PoPToP.
–
Para configurar una vpn bajo protocolo pptp necesitamos un servidor, un cliente (tantos como
deseemos) y una conexión a Internet para cada uno de ellos.
El servidor puede ser una distribución cualquiera de Linux configurada con el servicio
Poptop (www.poptop.org), que es el encargado de ofrecer conexiones PPTP. No necesita
grandes requisitos de hardware y con un simple Pentium 300 con 128 megas de RAM
podremos ofrecer conexiones a la vpn a un máximo de 15 a 20 clientes.
El cliente puede seruna máquina con cualquier Windows, desde Windows 98 hasta Windows
2003, pasando por XP o Windows 2000. En todo caso, se recomienda usar Windows 2000 o
XP ya que su soporte de compresión de tráfico y su mayor nivel de encriptación ofrecerán un
mejor rendimiento al conectarse a la vpn. En cuanto a los protocolos de red necesarios,
PPTP permite el uso de redes privadas virtuales sobre redes TCP/IP ya existentes, como
Internet, pero preservando el uso de los protocolos de red, direcciones de nodo y nombres
de máquinas ya existentes en la red privada.
Por tanto, no se requiere el uso de nuevos protocolos ni cambios en las
aplicaciones de red. Mediante el "túnel privado" que se establece a través de
la red pública TCP/IP, pueden usarse, por ejemplo, los protocolos IPX y
NetBEUI usados en la red privada para la ejecución de las aplicaciones de
red.
En cuanto a las garantias de seguridad que ofrece PPTP, la autentificación de
usuarios se realiza a través de los protocolos PAP y CHAP). PPTP hace uso de la seguridad
que da el protocolo PPP.
La autentificación MSCHAP se utiliza para validar las credenciales del usuario remoto
contra dominios NT a través del servidor Linux con PPTP, capaz de emular cualquier tipo de
conexión y protocolo desde y hacia sistemas Windows. Sólo los usuarios con permiso para
ello pueden realizar la conexión. Una vez que se comprueba que el usuario tiene permiso (es
decir, que su nombre de usuario y contraseñas existen) para iniciar una sesión, se genera
una "llave" de 40 bits en Windows 98 y NT y de 128 bits en XP y Windows 2000 a partir de la
clave del usuario (llave que SIEMPRE viaja ya encriptada por la red) que es utilizada para
encriptar a su vez los datos del usuario (encriptación RC4).
Implementacion de cliente y servidor
En Linux tenemos soporte para vpns bajo protocolo pptp grácias al proyecto Poptop,
encargado de la creación del programa pptpd que es el que usaremos para crear nuestra
vpn. Básicamente y con el uso de este programa, conseguiremos que los clientes Windows
accedan a nuestra red local asignándoles un interfaz de red nuevo en el servidor pptp (un
interfaz que realmente es virtual, no va asociado a ningún hardware en especial) con una
dirección IP capaz de llegar a nuestra redes locales. El procolo pptp, al estar basado en
conexiones punto a punto con protocolo ppp, creará en nuestro servidor sencillos interfaces
ppp. A cada conexión pptp nueva tendremos un nuevo interfaz ppp, empezando desde el
ppp0 y subiendo a 1, 2, 3, etc a cada nueva conexión simultánea que obtengamos.
Para la instalación del soporte pptp para Linux tenemos dos opciones, o bien usar el
soporte pptp simple sin encriptación, con el cual nos ahorramos tener que modificar nuestro
kernel (el núcleo del sistema) para añadirle soporte de encriptación MPPE o bien optar por
acabar modificando nuestro kernel para añadirle dicho soporte, con lo que obtendremos un
sistema mucho mas seguro al estar protegido por una potente encriptación de hasta 128 bits.
Tendremos tres archivos básicos:
/etc/pptpd.conf
/etc/ppp/options.pptp
/etc/ppp/chapsecrets
Por otro lado, tenemos el archivo /etc/init.d/pptpd con el cual, pasándole la orden stop
o start podremos arrancar o parar nuestra vpn.
/etc/pptpd.conf
speed 115200
option /etc/ppp/pptpdoptions
debug
localip 192.168.2.1
remoteip 192.168.5.1100
Este archivo tiene muy pocas opciones de configuración que necesitemos considerar.
Las opcion speed no tiene ninguna utilidad si nuestro servidor va a funcionar sobre redes
ethernet. Pongamos lo que pongamos, siempre irá a la máxima velocidad que nuestra red
permita.
La opción debug nos permitirá ver en los logs todos y cada uno de los pasos y procesos que
realiza nuestro servidor pptp para establecer las conexiones de los clientes. Tenerla activada
puede ser una buena ayuda cuando nuestro servidor no funciona y no sabemos porque, ya
que obtendremos mucha más información de los logs del sistema y podremos buscar entre
ellos donde estamos fallando.
La opción option especifica el archivo de opciones de conexión (donde especificamos
encriptación, servidores dns, etc), que por defecto es /etc/ppp/pptpdoptions y que en
principio no necesitamos cambiar para nada. Las opciones localip y remoteip si que tienen
bastante mas importáncia ya con ellas especificaremos los rangos ip de nuestra vpn.
En localip bastará con especificar una de las IPs locales que pueda tener nuestro servidor
pptp (si solo tiene una, pues esa misma servirá).
En remoteip tendremos que especificar el rango de direcciones IP que asignaremos a
aquellos clientes que se conecten a nuestra red via pptp. Podemos usar direcciones de un
rango de red ya creado (obviamente, deben ser direcciones IP que nadie esté utilizando) o
bien crear un rango de red própio que solamente utilizarán las máquinas que se conecten
usando la vpn y que se comunicará con el resto de nuestros rangos locales grácias al mismo
servidor pptp, que automáticamente enrutará las maquinas que entren vpn hacia todos los
rangos de red que el mismo servidor pptp sea capaz de encontrar en su misma red local.
Podemos especificar grupos de IPs, para no agotar todo el rango. Por ejemplo, remoteip
192.168.5.1100 solo asignará ips entre 192.168.5.1 hasta la 192.168.5.100.
/etc/ppp/options.pptp
lock debug # Sólo si queremos aún mas
debug
proxyarp # Sólo si queremos caché de arp
chap
+chapms
+chapmsv2
mppe40
mppe128
mppestateless
/etc/ppp/chapsecrets
cliente servidor contraseña dirección ip

juan pptpd password 192.168.0.3 # Ip estática
pablo pptpd password * # ip dinamica
UNIDAD 4
IPSEC Kernel 2.6
INTRODUCCION:
Hay una solución libre de VPN basada en software para Linux llamada FreeS/Wan que
utiliza una implementación estandarizada de IPSec (o Protocolo de Internet de Seguridad).
Estas soluciones VPN, sin importar si están basadas en hardware o software, actúan como
enrutadores especializados que se colocan entre la conexión IP desde una oficina a la otra.
Cuando un paquete es transmitido a un cliente, lo envía a través del enrutador o
puerta de enlace, el cual posteriormente añade información de cabecera para el
enrutamiento y autenticación llamado la Cabecera de autenticación (AH).
Los datos son encriptados y encapsulados con instrucciones de descifrado y manejo
llamado Encapsulating Security Payload (ESP).
El enrutador VPN receptor extrae la información y la enruta a su destino (bien sea una
estación de trabajo o un nodo en la red). Usando una conexión de redared, el nodo
receptor en la red local recibe los paquetes descifrados y listos para ser procesados.
El proceso de encriptación/descifrado en una conexión VPN de redared es
transparente al nodo local.
Centos es compatible con IPsec para la conexión entre hosts y redes remotos
utilizando un túnel seguro en un transportador de red común tal como la Internet. IPsec se
puede implementar usando una conexión hostahost (una computadora a la otra) o de reda
red (una LAN/WAN a la otra).
La implementación IPsec en Centos utiliza el Intercambio de llaves en Internet (IKE),
el cual es un protocolo implementado por el Internet Engineering Task Force (IETF), a ser
usado para la autenticación mutua y asociaciones seguras entre sistemas conectándose.
Una conexión IPsec se divide en dos fases lógicas.
En la fase 1, un nodo IPsec inicializa la conexión con el nodo o red remota. El
nodo/red remota verifica las credenciales del nodo solicitante y ambos lados negocian el
método de autenticación para la conexión.
En sistemas Centos, una conexión IPsec utiliza el método de llave precompartida o pre
shared key de autenticación de nodo IPsec.
La fase 2 de la conexión IPsec es donde se crea una asociación de seguridad (SA)
entre nodos IPsec. Esta fase establece una base de datos SA con información de
configuración, tal como el método de encriptación, parámetros de intercambio de llaves
secretas y más. Esta fase maneja realmente la conexión IPsec entre nodos y redes.
La implementación de Centos de IPsec utiliza IKE para compartir las llaves entre hosts a
través de la Internet.
El demonio racoon de manejo de llaves se encarga de la distribución e intercambio de
llaves IKE.
Instalación de IPsec
La implementación de IPsec requiere que esté instalado el paquete RPM ipsectools en
todos los hosts IPsec (si se está utilizando una configuración de hostahost) o enrutadores
(si se está usando una configuración de redared).
El paquete RPM contiene las bibliotecas esenciales, los demonios y los archivos de
configuración para ayudar en la configuración de una conexión IPsec, incluyendo:
• /lib/libipsec.so — biblioteca que contiene la interfaz de administración de sockets de
llaves confiables PF_KEY entre el kernel de Linux y la implementación IPsec usada en
Red Hat Enterprise Linux.
• /sbin/setkey — manipula la administración de llaves y los atributos de seguridad de
IPsec en el kernel. Este ejecutable es controlado por el demonio de manejo de llaves
racoon. Para más información sobre setkey, consulte la página man setkey(8).
• /sbin/racoon — el demonio de manejo de llaves IKE, utilizado para gestionar y
controlar las asociaciones de seguridad y el compartir de llaves entre sistemas
conectados IPsec. Este demonio se puede configurar modificando el archivo
/etc/racoon/racoon.conf. Para más información sobre racoon, consulte la página man
de racoon(8).
• /etc/racoon/racoon.conf — El archivo de configuración del demonio racoon
utilizado para configurar los diferentes aspectos de la conexión IPsec, incluyendo los
métodos de autenticación y algoritmos de encriptación usados en la conexión. Para
ver un listado completo de las directivas disponibles, consulte la página man de
racoon.conf(5).
Configuración IPsec de hostahost
Los requerimientos de una conexión hostahost son mínimos, como lo es la configuración de
IPsec en cada host. Los hosts solamente necesitan una conexión dedicada al transportador
de red (tal como la Internet) y Red Hat Enterprise Linux para crear la conexión IPsec.
El primer paso en la creación de una conexión es reunir la información del sistema y de la
red de cada estación de trabajo. Para una conexión hostahost, necesita la información
siguiente:
• La dirección IP para ambos hosts
• Un nombre único para identificar la conexión IPsec y distinguirla de los otros
dispositivos o conexiones (por ejemplo, ipsec0)
• Una llave encriptada fija o una generada automáticamente por racoon
• Una llave precompartida que se utiliza para iniciar la conexión e intercambiar las
llaves de encriptación durante la sesión
Por ejemplo, suponga que la Estación A y la Estación B desean conectarse a través
de un túnel IPsec. Ellas desean conectarse usando una llave precompartida con el valor de
foobarbaz y los usuarios acuerdan dejar que racoon automáticamente genere y comparta
una llave de autenticación entre cada host.
Ambos usuarios de los hosts deciden nombrar sus conexiones como ipsec0.
Lo siguiente es el archivo ifcfg para una conexión IPsec de hostahost para la
Estación A con la Estación B (el nombre único para identificar la conexión en este ejemplo es
ipsec0, por lo que el archivo resultante es llamado:
/etc/sysconfig/networkscripts/ifcfgipsec0:
DST=X.X.X.X
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
La Estación A reemplazará X.X.X.X con la dirección IP de la Estación B, mientras que
la Estación B, reemplaza X.X.X.X con la dirección IP de la Estación A. La conexión es
configurada para iniciarse luego del arranque (ONBOOT=yes) y utiliza el método de
autenticación de llave precompartida (IKE_METHOD=PSK).
Lo siguiente es el contenido del archivo de llave precompartida llamado:
/etc/sysconfig/networkscripts/keysipsec0 que ambas estaciones de trabajo necesitan
para autenticarse mutuamente. Los contenidos de este archivo deberían ser idénticos en
ambas estaciones de trabajo y solamente el usuario root debería ser capaz de leer o escribir
en el mismo.
IKE_PSK=foobarbaz
Para cambiar la llave de autenticación en cualquier momento, modifique el archivo
keysipsec0 en ambas estaciones de trabajo. Ambas llaves deben ser idénticas para una
conectividad apropiada.
A continuación se muestra la configuración específica para la fase 1 de la conexión al
host remoto. El archivo es llamado X.X.X.X.conf (reemplace X.X.X.X con la dirección IP del
enrutador IPsec remoto). Observe que este archivo es generado automáticamente una
vez que el túnel IPsec es activado y no se debería modificar directamente.
;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
El archivo de configuración predeterminado para la fase 1 creado cuando se inicializa una
conexión IPsec contiene las siguientes declaraciones utilizadas por la implementación
CentOS de IPsec:
remote X.X.X.X
Especifica que las estrofas subsecuentes de este archivo de configuración sólo aplican
al nodo remoto identificado por la dirección IP X.X.X.X
exchange_mode aggressive
La configuración predeterminada para IPsec en Red Hat Enterprise Linux utiliza un
método de autenticación agresivo, que reduce la sobrecarga de la conexión a la vez
que permite la configuración de muchas conexiones IPsec con múltiples hosts.
my_identifier address
Define el método de autenticación a utilizar cuando se autentifican nodos. Red Hat
Enterprise Linux utiliza direcciones IP para identificar a los nodos.
encryption_algorithm 3des
Define el cifrado de encriptación utilizado durante la autenticación. Por defecto, se
utiliza Triple Data Encryption Standard (3DES).
Especifica el algoritmo hash utilizado durante la negociación de la fase 1 entre nodos.
Por defecto, se utiliza el Secure Hash Algorithm versión 1.
authentication_method pre_shared_key
Define el método de autenticación utilizado durante la negociación de nodos. Por
defecto, Red Hat Enterprise Linux utiliza llaves precompartidas para la autenticación.
dh_group 2
Especifica el número de grupo DiffieHellman para establecer llaves de sesión
generadas dinámicamente. Por defecto, se utiliza el grupo de 1024 bits.
El archivo /etc/racoon/racoon.conf debería ser idéntico en todos los nodos IPsec excepto
por la declaración include "/etc/racoon/X.X.X.X.conf". Esta declaración (y el archivo que
referencia) es generado cuando se activa el túnel IPsec. Para la Estación A, X.X.X.X en la
declaración include, es la dirección IP de la Estación B. Lo opósito es cierto también para la
Estación B. A continuación se muestra un archivo típico racoon.conf cuando se activa la
conexión IPsec.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
Este archivo predeterminado racoon.conf incluye rutas definidas para la configuración IPsec,
archivos de llaves precompartidas y certificados. Los campos en sainfo anonymous
describen el SA de la fase 2 entre nodos IPsec — la naturaleza de la conexión IPsec
(incluyendo los algoritmos de encriptación soportados) y el método de intercambio de llaves.
La lista siguiente define los campos de la fase 2.
sainfo anonymous
Denota que SA puede inicializarse de forma anónima con cualquier par siempre que las
credenciales IPsec coincidan.
pfs_group 2
Define el protocolo de intercambio de llaves DiffieHellman, el cual determina el método
en el cual los nodos IPsec establecen una sesión temporal mutua para la segunda fase
de conectividad de IPsec. Por defecto, la implementación de Red Hat Enterprise Linux
de IPsec utiliza el grupo 2 (o modp1024) de los grupos de intercambio de llaves
criptográficas de DiffieHellman. El grupo 2 utiliza una exponenciación modular de 1024
bits que evita que los atacantes descifren transmisiones IPsec previas aún si una llave
privada está comprometida.
lifetime time 1 hour
Este parámetro especifica el ciclo de vida de un SA y se puede cuantificar por veces o
por bytes de datos. La implementación de Red Hat Enterprise Linux de IPsec especifica
un tiempo de vida de una hora.
encryption_algorithm 3des, blowfish 448, rijndael
Especifica los códigos de encriptación soportados para la fase 2. Red Hat Enterprise
Linux soporta 3DES, 448bit Blowfish y Rijndael (el código utilizado en el Advanced
Encryption Standard o AES).
authentication_algorithm hmac_sha1, hmac_md5
Lista los algoritmos hash soportados para la autenticación. Los modos soportados son
los códigos de autenticación de mensajes en hash (HMAC) sha1 y md5.
compression_algorithm deflate
Define el algoritmo de compresión Deflate para el soporte de IP Payload Compression
(IPCOMP), lo que permite transmisiones potenciales más rápidas de datagramas IP
sobre conexiones más lentas.
Para iniciar la conexión, reinicie la estación de trabajo o ejecute el comando siguiente
como root en cada host:
/sbin/ifup ipsec0
Para verificar la conexión IPsec, ejecute la utilidad tcpdump para ver los paquetes de
red que están siendo transferidos entre los hosts (o redes) y verificar que están encriptados
con IPsec.
El paquete debería incluir una cabecera AH y se deberían mostrar como paquetes ESP. ESP
significa que están encriptados. Por ejemplo:
17:13:20.617872 pinky.example.com > ijin.example.com: \
AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)
Configuración de IPsec de redared
IPsec también se puede configurar para conectar una red completa (tal como una LAN
o una WAN) a una red remota a través de una conexión redared. Una conexión de reda
red requiere la configuración de enrutadores IPsec en cada lado de las redes conectantes
para procesar y enrutar la información de forma transparente desde un nodo en una LAN a
otro nodo en una LAN remota.
La información necesaria para la conexión redared incluye:
• Las direcciones IP accesibles externamente de los enrutadores IPsec dedicados
• Los intervalos de direcciones de red de las LAN/WAN servidas por los enrutadores
IPsec (tales como 192.168.0.0/24 o 10.0.1.0/24)
• Las direcciones IP de los dispositivos de puertas de enlace que enrutan los datos
desde un nodo de la red a la Internet:
• Un nombre único para identificar la conexión IPsec y distinguirla de los otros
dispositivos o conexiones (por ejemplo, ipsec0)
• Una llave encriptada fija o una generada automáticamente por racoon
• Una llave precompartida que inicia la conexión e intercambia las llaves de
encriptación durante la sesión
Por ejemplo, suponga una LAN A (lana.example.com) y una LAN B
(lanb.example.com) que desean conectarse entre ellas a través de un túnel IPsec.
La dirección de red para la LAN A están en el intervalo 192.168.1.0/24, mientras que
LAN B utiliza el intervalo 192.168.2.0/24.
La dirección IP de la puerta de enlace es 192.168.1.254 para la LAN A y 192.168.2.254
para la LAN B.
Los enrutadores IPsec están separados de cada puerta de enlace de las LANs y
utilizan dos dispositivos de redes: eth0 está asignado a una dirección IP estática accesible
externamente la cual accesa la Internet, mientras que eth1 actúa como un punto de
enrutamiento para procesar y transmitir paquetes LAN desde un nodo de la red a los nodos
de redes remotos.
La conexión IPsec entre cada red utiliza una llave precompartida con el valor de
r3dh4tl1nux, y los administradores de A y B acuerdan dejar que racoon genere
automáticamente y comparta una llave de autenticación entre cada enrutador IPsec.
El administrador de la LAN A decide nombrar la conexión IPsec ipsec0, mientras que
el administrador de la LAN B llama a su conexión IPsec ipsec1.
Lo siguiente son los contenidos del archivo ifcfg para una conexión IPsec de redared
para la LAN A.
El nombre único para identificar la conexión en este ejemplo es ipsec1, por lo que el
archivo resultante es llamado /etc/sysconfig/networkscripts/ifcfgipsec1.
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
La conexión se configura para iniciarse en el arranque (ONBOOT=yes) y utiliza un
método de autenticación de llave precompartida (IKE_METHOD=PSK).
El administrador para la LAN A ingresa la puerta de enlace destino, la cual es la
puerta de enlace para la LAN B (DSTGW=192.168.2.254) así como también la puerta de
enlace fuente, la cual es la dirección IP de la puerta de enlace para la LAN A
(SRCGW=192.168.1.254).
El administrador luego introduce la red destino, la cual es el intervalo de red para la
LAN B (DSTNET=192.168.2.0/24) así como también la red fuente (SRCNET=192.168.1.0/24).
Finalmente, el administrador ingresa la dirección IP destino, la cual es la dirección IP
accesible externamente para la LAN B (X.X.X.X).
Lo siguiente es el contenido del archivo de la llave precompartida llamado
/etc/sysconfig/networkscripts/keysipsecX (donde X es 0 para la LAN A y 1 para la LAN B)
que ambas redes utilizan para autenticarse mutuamente. Los contenidos de este archivo
deberían ser idénticos y solamente el usuario root debería tener acceso a leer o escribir en
este archivo.
IKE_PSK=r3dh4tl1nux
Para cambiar la llave de autenticación en algún momento, modifique el archivo keys
ipsecX en ambos enrutadores IPsec. Ambas llaves deber ser idénticas para obtener una
conectividad apropiada.
Lo siguiente son los contenidos del archivo de configuración /etc/racoon/racoon.conf
para la conexión IPsec. Observe que la línea include al final del archivo es generado
automáticamente y solamente aparece si el tunel IPsec se está ejecutando.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
A continuación se muestra el archivo específico para la conexión a la red remota. El
archivo es llamado X.X.X.X.conf (reemplace X.X.X.X con la dirección IP del enrutador IPsec
remoto). Observe que este archivo es generado automáticamente una vez que el túnel IPsec
es activado y no se debería modificar directamente.
;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
Antes de iniciar la conexión IPsec, se debería activar el reenvío IP en el kernel. Como
usuario root en el intérprete de comandos, active el reenvío IP:
1. Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1.
2. Ejecute el comando siguiente para activar el cambio:
sysctl p /etc/sysctl.conf
Para iniciar la conexión IPsec, reinicie los enrutadores IPsec o ejecute el comando
siguiente en cada enrutador como usuario root:
/sbin/ifup ipsec0
Las conexiones son activadas y ambas LAN A y LAN B son capaces de comunicarse
entre ellas. Los enrutadores se crean automáticamente a través del script de inicialización
que se llama ejecutando ifup en la conexión IPsec. Para mostrar una lista de rutas para la
red, ejecute el comando siguiente:
/sbin/ip route list
Para evaluar la conexión IPsec, ejecute la utilidad tcpdump en el dispositivo enrutable
externamente (eth0 en este ejemplo) para así ver los paquetes de red que están siendo
transmitidos entre los hosts (o redes) y verificar que están encriptados a través de IPsec. Por
ejemplo, para verificar la conectividad IPsec de la LAN A, escriba lo siguiente:
tcpdump n i eth0 host lana.example.com
El paquete debería incluir una cabecera AH y se deberían mostrar como paquetes
ESP. ESP significa que están encriptados. Por ejemplo (las barras oblícuas denotan la
continuación de una línea):
12:24:26.155529 lanb.example.com > lana.example.com:
AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com:
ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipipproto4)
UNIDAD 5
Tuneles con SSH
INTRODUCCION SSH / OpenSSH
SSH es el nombre de un protocolo y del programa que lo implementa.
Este protocolo sirve para acceder a máquinas a través de una red, de forma similar a como
se hacía con telnet. La diferencia principal es que SSH usa técnicas de cifrado para que
ningún atacante pueda descubrir el usuario, la contraseña de la conexión y ni lo que se
escribe durante toda la sesión; aunque es posible atacar este tipo de sistemas por medio de
ataques de REPLAY y manipular así la informacion entre destinos.
Al igual que telnet, sólo permite conexiones tipo terminal de texto, aunque puede redirigir el
tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X arrancado.
OpenSSH es la implementación de cliente y servidor abierta y gratuita para estos protocolos.
Portforwarding
Veamos cómo llevar esto a cabo. La clave está en usar la opción "L" de SSH, que se
encarga de todo el proceso de "portforwarding".
El siguiente ejemplo muestra cómo utilizar el puerto 10110 de nuestra máquina para
establecer una comunicación segura con el puerto 110 del servidor popmail.correo.net:
$ ssh P L 10110:popmail.correo.net:110
El símbolo de dólar obviamente no pertenece al comando, indica que lo ha realizado
un usuario sin privilegios de root.
Esto es un punto importante: si queremos utilizar puertos privilegiados por debajo de
1024 ("wellknown ports"), deberemos tener privilegios de root (por lo menos en un sistema
con una configuración normal, alejado del "enfoque" de seguridad de Windows98 o
similares).
Si no disponemos de dichos privilegios, tendremos que optar por la alternativa de
utilizar un puerto superior a 1024, como en el ejemplo. Una manera fácil de no liarse con
esto es sumar 10000 al número de puerto estándar, así el 110 sería el 10110 en nuestra
máquina, el 10080 el 80, o el 16667 el 6667.
Configurar un servidor SSH es normalmente bastante simple y está limitado a las
utilidades SSH. De esta manera, se puede utilizar el túnel SSH aún cuando no se tenga
administración del sistema destino, siempre y cuando SSH funcione junto con el protocolo
que se desea "tunelear". Si esta configuración no funciona, se debería chequear el archivo
/etc/ssh/sshd_config, buscando la siguiente línea.
AllowTcpForwarding yes
Sí "AllowTcpForwarding" no está en "yes", el servidor de SSH rechazará el tráfico
tuneleado. El valor por defecto es "yes", por lo que usualmente esto no causará problemas,
pero es digno de comprobar si no se consigue hacer funcionar el SSH Tunneling.
Las opciones más importantes para el programa cliente SSH son:
• N Le dice al protocolo que no ejecute un login remoto. Si se omite esto, SSH intentará
abrir una sesión interactiva (o con algunas otras opciones, ejecutar un programa
remoto).
• f permite ejecutar el programa en el backgroung después de haber pedido el
password.
• L puerto_local:servidor:puerto_del_servidor especifica un número de cosas: el puerto
local SSH a escuchar, el servidor al cual los datos han de ser enviados, y el puero en
el servidor al cual los datos han de ser enviados.
• sshserver provee el nombre de host del servidor SSH, opcionalmente precedido por
un usuario y una arroba (@).
Normalmente, el nombre del servidor sera el mismo que el especificado en el parámetro L,
pero es posible conectarse a un servidor SSH remoto y hacer que este envie tráfico a
algunas otras computadoras que no corren un servidor SSH. Si se incluye un nombre de
usuario, la conexión remota tendrá ese nombre, aunque el tunel no lo usará; es posible usar
otro nombre de usuario para esto.
Por ejemplo, cuando se tipea como root en un cliente el siguiente comando, "tunelea" el
tráfico IMAP (puerto 143) desde la computadora local al puerto IMAP en el servidor
mail.test.cl, usando la cuenta "pepe" en el sistema remoto.
# ssh N f L \
143:mail.test.cl:143 \
pepe@mail.test.cl
Forwarding de X
Un caso especial del tuneleado SSH es la capacidad del protocolo para manejar
conexiones a servidores X.
En este caso, el servidor X corre en una computadora SSH cliente, y el cliente X (esto
es, el programa que se desea ejecutar) reside en la computadora servidor de SSH.
El servidor SSH hace dobre trabajo, ocmo un servidor SSH y como un servidor proxy
X, mientras que el cliente SSH funciona como un cliente SSH y un cliente proxy X.
Para hacer que esta configuración funcione, los programas X deben saber como
conectarse a la instancia del servidor X del servidor SSH en vez de conectarse al servidor X
que corre en el sistema local.
El servidor SSH se conecta por lo tanto al puerto X apropiado y setea la variable de
entorno DISPLAY para apuntar los clientes a ese puerto.
Para trabajar de esta forma, se deben setear las opciones apropiadas en los archivos
de configuración del servidor y cliente X. En particular se debe chequear el archivo
/etc/ssh/ssh_config y buscar la siguiente línea
ForwardX11 yes
Si esta línea esta seteada en "no", se debe cambiarla a "yes". Alternatívamente, se
puede pasar el parámetro X a ssh cuando se lo llama para habilitar la redirección X (prestar
atencion a que es X mayúscula, la x minúscula deshabilita el forwarding!).
En el servidor SSH, chequear el archivo /etc/ssh/sshd_config y buscar la siguiente línea:
X11Forwarding yes
Como con la opción equivalente del cliente, hay que asegurarse que está seteada en "yes".
También, hay que asegurarse de chequear los archivos correctos (ssh_config para el cliente
y sshd_config para el servidor). La diferencia de sólo un caracter en los nombres de archivos
puede causar confusión.
SSH sin password
Normalmente, ssh pide el usuario cuando alguien se conecta. Esto puede hacer que el
uso automático de un túnel SSH se torne tedioso, debido a que se debe tipear el comando
para realizar la conexión (posiblemente como root) e ingresar manualmente el password
antes de usar el enlace. Para solucionar este problema, se puede configurar el SSH para
conectarse sin passwords. De esta forma, SSH usará claves privadas y públicas. Para usar
este sistema, han de seguirse los siguientes pasos:
1 Crear par de claves (publicas/privadas)
[root@localhost ~]# sshkeygen t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
f7:7c:69:9d:53:e0:06:0c:d7:b1:04:51:cc:d9:6f:28 root@localhost.localdomain
2 Crear par de claves (publicas/privadas)
scp /root/.ssh/id_rsa.pub 10.0.0.254:/root/.ssh/authorized_keys

142-Manual VPN

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

142-Manual VPN

Transféré par

Droits d'auteur :

Formats disponibles

Resumen Ejecutivo

Principios que nos inspiran

Presentación Corporativa Linux Latin América 2008

Sus objetivos de Calidad

Presentación Corporativa Linux Latin América 2008

Levantamiento y Detalle de Requerimientos - Fase Inicial de Asesoría

Presentación Corporativa Linux Latin América 2008

- Soluciones de Telefonía y Voz sobre IP con Asterisk.

- Servidores de Archivos - Controladores de Dominio (Samba / OpenLDAP) - Single

- Seguridad. Firewall - VPNs - Detector de Intrusos - Análisis Forense - Proxy -

- Herramientas de Monitoreo de Servidores y Red. Nagios - Cacti - MRTG - Ethereal

- Mon - Tunning para servidores de bases de datos Oracle y Sybase.

- Clusterización de Servidores : Alta Disponibilidad - Balanceo de Carga - Oracle RAC.

Implementación de Soluciones Comerciales para Linux

Soporte y Asistencia Técnica

Presentación Corporativa Linux Latin América 2008

- Es la empresa chilena con más experiencia en soluciones linux en el mercado nacional.

Es la que posee el mayor número de ingenieros certificados RHCE (Certified Engineer)

Presentación Corporativa Linux Latin América 2008

Administración Linux -LC ADM 100

Resolución de problemas- LC ADM 200

Seguridad Linux – LC SEG 200

Infraestructura – LC INF 300

Monitoreo de Red – LC SEG 201

VPN- LC SEG 200

Cluster- LC CLU 300

Asterisk - LC AST 300

XML- lC XML 100

Java – LC JAV 200

J2EE – LC J2E 400

PHP MYSQL – LC PHP 200

PHP POSTGRE SQL – LC PHP 201

Perl – LC PER 100

Administración de PostgreSQL (Intermedio y Avanzado)

CHILE ARGENTINA MEXICO

# & 

' & ' 

 )"$ ' 

 -")     

 ."$ 

 /" $ ' 

6     

6     

6       

   !3;$ 

   !(" $               

   !." $ ' 

cliente servidor contraseña dirección ip

Vous aimerez peut-être aussi

# &

' & '

)"$ '

-")

."$

/" $ '

6

6

6

!3;$

!(" $

!." $ '