CLICK HERE FOR THOUSANDS OF FREE BLOGGER TEMPLATES »

Thursday 11 November 2010

Material Apoyo Geometria

Wednesday 25 March 2009

Servidor Proxy con autenticación de usuarios de servicio de directorio.

objetivos:
implementar servidor proxy.
implementar politicas de acceso, restriccion por URL, extenciones de archivo, mimetypes y por acceso de horarios.
implementar listas negras para control de acceso.
implementar autenticacion con usuarios de un servicio de direcctorio.
implementar un analizador de trafico para generar reportes estadisticos con acceso seguro para la visualizacion de los reportes.


servidor proxy
Un servidor proxy es un programa, dispositivo u equipo intermediario situado entre los equipos la red (lan) e Internet. Puede utilizarse para registrar el uso de Internet y también para bloquear el acceso a un sitio Web. la finalidad más habitual del servidor proxy, es permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.

Generalmente el servidor proxy se utiliza para la Web. Se trata entonces de un proxy HTTP. Sin embargo, puede haber servidores proxy para cada protocolo de aplicación (FTP, etc.).

**El principio operativo básico de un servidor proxy es bastante sencillo: se trata de un servidor que actúa como "representante" de una aplicación efectuando solicitudes en Internet en su lugar. De esta manera, cuando un usuario se conecta a Internet con una aplicación del cliente configurada para utilizar un servidor proxy, la aplicación primero se conectará con el servidor proxy y le dará la solicitud. El servidor proxy se conecta entonces al servidor al que la aplicación del cliente desea conectarse y le envía la solicitud. Después, el servidor le envía la respuesta al proxy, el cual a su vez la envía a la aplicación del cliente.

**La mayoría de los proxys tienen una caché, es decir, la capacidad de guardar en memoria (“en caché”) las páginas que los usuarios de la red de área local visitan comúnmente para poder proporcionarlas lo más rápido posible. De hecho, el término "caché" se utiliza con frecuencia en informática para referirse al espacio de almacenamiento temporal de datos (a veces también denominado "búfer").

Un servidor proxy con la capacidad de tener información en caché (neologismo que significa: poner en memoria oculta) generalmente se denomina servidor "proxy-caché".

Esta característica, implementada en algunos servidores proxy, se utiliza para disminuir tanto el uso de ancho de banda en Internet como el tiempo de acceso a los documentos de los usuarios.

Sin embargo, para lograr esto, el proxy debe comparar los datos que almacena en la memoria caché con los datos remotos de manera regular para garantizar que los datos en caché sean válidos.

**Por otra parte, al utilizar un servidor proxy, las conexiones pueden rastrearse al crear registros de actividad (logs) para guardar sistemáticamente las peticiones de los usuarios cuando solicitan conexiones a Internet.

Gracias a esto, las conexiones de Internet pueden filtrarse al analizar tanto las solicitudes del cliente como las respuestas del servidor. El filtrado que se realiza comparando la solicitud del cliente con una lista de solicitudes autorizadas se denomina lista blanca; y el filtrado que se realiza con una lista de sitios prohibidos se denomina lista negra. Finalmente, el análisis de las respuestas del servidor que cumplen con una lista de criterios (como palabras clave) se denomina filtrado de contenido.

**Como el proxy es una herramienta intermediaria indispensable para los usuarios de una red interna que quieren acceder a recursos externos, a veces se lo puede utilizar para autenticar usuarios, es decir, pedirles que se identifiquen con un nombre de usuario y una contraseña. También es fácil otorgarles acceso a recursos externos sólo a las personas autorizadas y registrar cada uso del recurso externo en archivos de registro de los accesos identificados.

Este tipo de mecanismo, cuando se implementa, obviamente genera diversos problemas relacionados con las libertades individuales y los derechos personales.

Mejoran el rendimiento.
Guardan en la memoria caché las páginas Web a las que acceden los sistemas de la red durante un cierto tiempo. Cuando un sistema solicita la misma página web, el servidor proxy utiliza la información guardada en la memoria caché en lugar de recuperarla del proveedor de contenidos. De esta forma, se accede con más rapidez a las páginas Web.

squid
Squid es un popular programa de software libre que implementa un servidor proxy y un demonio para caché de páginas web, publicado bajo licencia GNU GPL. Squid es un proxy caché para el apoyo a la Web HTTP, HTTPS, FTP y mucho más. Reduce el ancho de banda y mejora los tiempos de respuesta por el almacenamiento en caché y reutiliza frecuentemente páginas web solicitadas .

Tiene una amplia variedad de utilidades, desde acelerar un servidor web, guardando en caché peticiones repetidas a DNS y otras búsquedas para un grupo de gente que comparte recursos de la red, hasta caché de web, además de añadir seguridad filtrando el tráfico. Está especialmente diseñado para ejecutarse en la mayoría de sistemas operativos bajo entornos tipo Unix. tambien hay para entornos Windows.

Squid ha sido desarrollado durante muchos años y se le considera muy completo y robusto. Aunque orientado a principalmente a HTTP y FTP es compatible con otros protocolos como Internet Gopher. Implementa varias modalidades de cifrado como TLS, SSL, y HTTPS.

Squid es utilizado por cientos de Proveedores de Internet en todo el mundo para proporcionar a sus usuarios la mejor manera posible el acceso a la Web. Squid optimiza el flujo de datos entre el cliente y el servidor para mejorar el rendimiento y cachés con frecuencia utilizadas para ahorrar ancho de banda contenido. Squid puede tambien enrutar peticiones de contenido a los servidores de contenido en una amplia variedad de maneras de construir jerarquías de caché del servidor, que optimicen el rendimiento de red.

squidguard es un redirector de url utilizado para usar listas negras con el squid.
hay dos grandes ventajas para squidguard: es rapido y libre "gratis". SquidGuard esta publicado bajo licencia publica GNU.


ldap
ldap es un protocolo ligero de acceso a directorios "Lightweight Directory Acces Protocol", es un protocolo de tipo cliente-servidor para acceder a un servicio de directorio.

ldap es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos (aunque su sistema de almacenamiento puede ser diferente) a la que pueden realizarse consultas.

Habitualmente, almacena la información de login (usuario y contraseña) y es utilizado para autenticarse aunque es posible almacenar otra información (datos de contacto del usuario, ubicación de diversos recursos de la red, permisos, certificados, etc).

Uno o más servidores LDAP contienen los datos que conforman el árbol de directorio LDAP o base de datos troncal, el cliente LDAP se conecta con el servidor LDAP y le hace una consulta. El servidor contesta con la respuesta correspondiente, o bien con una indicación de donde puede el cliente hallar más información. No importa con que servidor LDAP se conecte el cliente ya que siempre observará la misma vista del directorio; el nombre que se le presenta a un servidor LDAP hace referencia a la misma entrada a la que haría referencia en otro servidor LDAP.

En conclusión, LDAP es un protocolo de acceso unificado a un conjunto de información sobre una red. El servicio de directorio LDAP se basa en un modelo cliente-servidor.

Sarg
Sarg es un programa para ver los informes de uso del Squid de una red. En palabras de su programador: Sarg es un Squid Analysis Report Generator que te permite ver "dónde" están yendo tus usuarios dentro de Internet. Sarg genera informes en html, con muchos campos, como: usuarios, Direcciones IP, bytes transmitidos, sitios web y tiempos.

netfilter/iptables

Netfilter es un framework disponible en el nucleo linux que permite interceptar y manipular paquetes de red. Dicho framework permite realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter es también el nombre que recibe el proyecto que se encarga de ofrecer herramientas libres para cortafuegos basados en linux.

El componente más popular construido sobre Netfilter es iptables, una herramientas de cortafuegos que permite no solamente filtrar paquetes, sino también realizar traduccion de direcciones de red (NAT) para ipv4 o mantener registros de log. El proyecto ofrecía compatibilidad hacia atrás con ipchains hasta hace relativamente poco, aunque hoy día dicho soporte ya ha sido retirado al considerarse una herramienta obsoleta. El proyecto Netfilter no sólo ofrece componentes disponibles como modulos del nucleo sino que también ofrece herramientas de espacio de usuario y librerías.

iptables es el nombre de la herramienta de espacio de usuario mediante la cual el administrador puede definir políticas de filtrado del tráfico que circula por la red. El nombre iptables se utiliza frecuentemente de forma errónea para referirse a toda la infraestructura ofrecida por el proyecto Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales como el connection tracking system o sistema de segumiento de conexiones, o que, que permite encolar paquetes para que sean tratados desde espacio de usuario. iptables es un software disponible en prácticamente todas las distribuciones de linux actuales.

Wednesday 4 March 2009

ipsec config

lo primero que debemos hacer es instalar el paquete ipsec-tools

apt-get install ipsec-tools

luego editamos el archivo ipsec-tools.conf, comenzamos por descomentar las siguientes lineas:

flush;
spdflush;

si queremos implementar AH agregamos las siguientes lineas:

#AH#
add IPlocal IPdestino ah 0x200 -A hmac-md5 0x"clave generada de 128 bits";
add IPdestino IPlocal ah 0x300 -A hmac-md5 0x"clave generada de 128 bits";
#
#politicas de seguridad#
spdadd 192.168.1.1 192.168.1.2 any -P out ipsec
ah/transport//require;
# esp/transport//require;
spdadd 192.168.1.2 192.168.1.1 any -P in ipsec
ah/transport//require;
# esp/transport//require;

(las claves mencionadas se generan con el siguiente comando)
dd if=/dev/random count=16 bs=1| xxd -ps para AH
dd if=/dev/random count=24 bs=1| xxd -ps para ESP

si queremos implementar ESP agregamos las siguientes lineas:

#ESP#
add IPlocal IPdestino esp 0x200 -E 3des-cbc 0x"clave generada de 192 bits";
add IPdestino IPlocal esp 0x300 -E 3des-cbc 0x"clave generada de 192 bits";
#
#politicas de seguridad#
spdadd 192.168.1.1 192.168.1.2 any -P out ipsec
esp/transport//require;
# ah/transport//require;
spdadd 192.168.1.2 192.168.1.1 any -P in ipsec
esp/transport//require;
# ah/transport//require;

y provamos si la configuracion esta buena con el siguiente comando:

setkey -f /etc/ipsec-tools.conf

luego instalamos el paquete tcpdump

apt-get install tcpdump

ahora podemos comprobar si esta funcionando con el siguiente comando:

tcpdump -i eth0 src host 192.168.1.1 or dst 192.168.1.2

hasta aqui todo debe estar correcto.

configuracion con racoon

instalamos el paquete racoon (durante la instalacion nos pregunta el modo de configuracion para el demonio IKE de racoon, al que configuraremos en modo directo)

apt-get install racoon

luego de la instalacion verificamos la creacion de tres archivos en el directorio racoon:

/etc/racoon/psk.txt

/etc/racoon/racoon.conf

/etc/racoon/racoon-tool.conf

ahora editamos el archivo psk.txt, comentamos todas las lineas y agregamos las siguientes:

pico /etc/racoon/psk.txt

#direcciones IPv4
192.168.1.1
192.168.1.2 0x"clave generada de 128 bits";
# USER_FQDN
cuenta@dominio.net
# FQDN

luego editamos el archivo racoon.conf, comentamos la linea #path certificate "/etc/racoon/certs"; para trabajar con clave precompartida, y copiamos o modificamos la remote.

path pre_shared_key "/etc/racoon/psk.txt";
#path certificate "/etc/racoon/certs";

remote 192.168.1.2 {
exchange_mode main,aggressive;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
generate_policy off;
}

sainfo address 192.168.1.2[any] any address 192.168.1.1/24[any] any {
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}

sainfo address 192.168.1.1[any] any address 192.168.1.2/24[any] any {
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}

luego reiniciamos el racoon.

/etc/init.d/racoon restart

y ya solo queda comprobar que todo esta funcionando correctamente, todo debe estar bien.

tcpdump -i eth0 src host 192.168.1.1 or dst 192.168.1.2

Saturday 28 February 2009

IPsec

IPsec es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el protocolo de internet (IP) autenticando y cifrando cada paquete ip en un flujo de datos. IPsec también incluye protocolos para el establecimiento de claves de cifrado. Los protocolos de IPsec actúan en la capa de red, la capa 3 del modelo osi.

Modo transporte
En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es cifrada y/o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticacion (AH), las direcciones IP no pueden ser trducidas, ya que eso invalidaría el hash. Las capas de transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador. (en modo transporte la conexion es nodo a nodo en la misma red)

modo tunel

En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado y autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo túnel se utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre internet. (en modo tunel la conexion es entre redes y se implementa IPsec es en los router)

Authentication header (AH)

AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) a través de algún algoritmo hash operando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la técnica de ventana deslizante y descartando paquetes viejos. AH protege la carga útil IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de fragmentos, TTL y suma de vefificacion de la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP número 51. Una cabecera AH mide 32 bits. (ah firma el paquete y brinda autenticidad, integridad, no repudio, "no garantiza confidencialidad") Algoritmos = sha md5

Encapsulating Security Payload (ESP)
El protocolo ESP proporciona autenticidad de origen, integridad y protección de confidencialidad de un paquete. ESP también soporta configuraciones de sólo cifrado y sólo autenticación, pero utilizar cifrado sin autenticación está altamente desaconsejado porque es inseguro. Al contrario que con AH, la cabecera del paquete IP no está protegida por ESP (aunque en ESP en modo túnel, la protección es proporcionada a todo el paquete IP interno, incluyendo la cabecera interna; la cabecera externa permanece sin proteger). ESP opera directamente sobre IP, utilizando el protocolo IP número 50. (cifra el paquete y brinda autenticidad, integridad, no repudio, confidencialidad) Algoritmos = 3des aes blowfish

IKE
El protocolo para Intercambio de Claves en Internet es el encargado en la infraestructura IPSec de proporcionar un entorno previo seguro para la compartición de una clave secreta y autenticación de los extremos. IKE utiliza el puerto 500 de UDP para establecer el intercambio de mensajes pertinente. Por lo general se implementa como una aplicación en espacio de usuario, al no formar parte del núcleo de muchos sistemas operativos. (autentica los participantes, nagocia las AS, escoger claves simetricas.

SP: politicas de seguridad
lo que queremos hacer y almacena protocolos a proteger, ip de los participantes, la SA asociada.

AS: asociasiones de seguridad
como lo vamos a hacer, unidireccional y almacena claves secretas, algoritmos, ip de los participantes.

spd y sad son las respectivas bases de datos de las politicas y las asociasiones.

Tuesday 24 February 2009

ssl

luego de instalar openssl y estar en la ruta /etc/ssl/
crearemos un directorio llamado CA y dentro crearemos otros dos llamados certificados y privado. El primero es donde se guardará una copia de cada certificado que firmemos y en el otro directorio se guardará la llave privada.

mkdir CA
cd CA
mkdir certificados privado

crear un par de archivos que en conjunto formarán la base de datos de los certificados autofirmados.
El archivo 'serial' contiene el número de serie de nuestros certificados, como apenas vamos a crear el primero su número de serie será 01, después de crearlo se actualizará a 02 y así sucesivamente.
El archivo 'index.txt' será la base de datos propiamente en base al número de serie.

echo '01' > serial
> index.txt

a continuacion mostramos un archivo de configuracion que puede ser usado
(copia el siguiente archivo dentro de CA con el nombre de openssl.cnf)

# ******************************************************************
# www.linuxtotal.com.mx
# sergio.gonzalez.duran@gmail.com
#
# Archivo de configuracion para openssl
#
# ***** openssl.cnf ******

dir = . # variable que establece el directorio de trabajo

# seccion que permite convertirnos en una CA
# solo se hace referncia a otra sección CA_default
[ ca ]
default_ca = CA_default

[ CA_default ]
serial = $dir/serial # archivo que guarda el siguiente número de serie
database = $dir/index.txt # archvio que guarda la bd de certificados
new_certs_dir = $dir/certificados # dir que guarda los certificados generados
certificate = $dir/cacert.pem # nombre del archivo del certificado raíz
private_key = $dir/privado/cakey.pem # llave privada del certificado raíz
default_md = md5 # algoritmo de dispersión usado
preserve = no # Indica si se preserva o no el orden de los campos del DN
# cuando se pasa a los certs.
nameopt = default_ca # esta opcion y la siguiente permiten mostrar detalles del
# certificado
certopt = default_ca
policy = policy_match # indica el nombre de la seccion donde se especifica que
# campos son obligatorios, opcionales y cuales deben ser
# iguales al certificado raíz

# seccion de politicas para la emision de certificados
[ policy_match ]
countryName = optional # match, obligatorio
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional # optional, campo opcional
commonName = supplied # supplied, debe estar en la petición
emailAddress = optional

[ policy_anything ]
countryName = optional # match, obligatorio
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional # optional, campo opcional
commonName = supplied # supplied, debe estar en la petición

# seccion que indica como los certificados deben ser creados
[ req ]
default_bits = 1024 # tamaño de la llave, si no se indica 512
default_keyfile = key.pem # nombre de la llave privada
default_md = md5 # algoritmo de dispersión a utilizar
string_mask = nombstr # caracteres permitidos en la mascara de la llave
distinguished_name = req_distinguished_name # seccion para el nombre distinguido (DN)
req_extensions = v3_req # seccion con mas extensiones que se añaden a la
# peticion del certificado

# seccion del nombre distinguido, el valor es el prompt que se vera en pantalla.
# datos del propietario del certificado.
# esta seccion define el contenido de datos de id que el certificado llevara.
[ req_distinguished_name ]
0.organizationName = Nombre de la organizacion
0.organizationName_default = ostau, S.A.
organizationalUnitName = Departamento o division
emailAddress = Correo electronico
emailAddress_max = 40
localityName = Ciudad o distrito
localityName_default = Leon
stateOrProvinceName = Estado o provincia
stateOrProvinceName_default = Guanajuato
countryName = Codigo del pais (dos letras)
countryName_default = MX
countryName_min = 2
countryName_max = 2
commonName = Nombre comun (hostname o IP)
commonName_max = 64

# si en la linea de comandos se indica la opcion -x509,
# las siguientes extensiones tambien aplican
[ v3_ca ]
# indica que se trata de un certificado CA raíz con autoridad para
# firmar o revocar otros certificados
basicConstraints = CA:TRUE

# especifica bajo que metodo identificar a la llave publica que sera certificada
subjectKeyIdentifier = hash

# especifica como identifcar la llave publica
authorityKeyIdentifier = keyid:always,issuer:always

# extensiones de la opcion req
[ v3_req ]
basicConstraints = CA:FALSE # los certificados firmados no son CA
subjectKeyIdentifier = hash

[ v3_client ]
basicContraints = CA:FALSE
extendedKeyUsage = ClientAuth
# ******************************************************************

luego comprobamos en este punto lo que debes de tener el directorio CA.

> ls -l
drwxr-xr-x 2 root root 4096 ene 26 13:23 certificados
-rw-r--r-- 1 root root 0 ene 26 13:24 index.txt
-rwxr--r-- 1 root root 4776 ene 26 2006 openssl.cnf
drwxr-xr-x 2 root root 4096 ene 26 13:23 privado
-rw-r--r-- 1 root root 3 ene 26 13:23 serial

todo esta casi listo para crear el certificado raíz, recordemos que este
certificado es el que nos convertira en una autoridad certificadora CA

openssl req -new -x509 -extensions v3_ca -keyout privado/cakey.pem -out cacert.pem -days 3650
-config ./openssl.cnf
Generating a 1024 bit RSA private key
....++++++
.......++++++
writing new private key to 'privado/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Nombre de la organizacion [ostau, S.A.]:
Departamento o division []:redes
Correo electronico []:admin@ostau.net
Ciudad o distrito [Leon]:
Estado o provincia [Guanajuato]:
Codigo del pais (dos letras) [MX]:
Nombre comun (hostname o IP) []:www.ostau.net

Lo anterior da por resultado dos archivos:
Un certificado raíz CA (cacert.pem) y una llave privada (privado/cakey.pem)
(La extensión ".pem" es de Privacy Enhanced Message)


El archivo cacert.pem es el que se puede mandar a nuestros clientes o usuarios del sistema, y que estos lo instalen o importen a su navegador, de esta manera quedaríamos como una CA más válida para el navegador y cada vez que el cliente se conecte a nuestro servidor, su navegador no mostraria el diálogo donde se pide si aceptar la conexión segurao no.

Verifiquemos el contenido del archivo cacert.pem y elcontenido de la llave privada
more cacert.pem
more privado/cakey.pem

En este punto, ya tenemos un certificado raíz que nos válida como CA, claro sin mas autoridad que nuestro propio dominio pero podemos crear certificados no solo para https, sino también spop, o simap o crear autentificación para vpn's a través de apliaciones como stunnel.
el siguiente procedimiento es crear una llave privada y una solicitud de certificado

openssl req -new -nodes -out ostau-cert.pem -config ./openssl.cnf
Generating a 1024 bit RSA private key
......................................................++++++
.......++++++
writing new private key to 'key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Nombre de la organizacion [ostau, S.A.]:
Departamento o division []:redes
Correo electronico []:admin@ostau.net
Ciudad o distrito [Leon]:
Estado o provincia [Guanajuato]:
Codigo del pais (dos letras) [MX]:
Nombre comun (hostname o IP) []:www.ostau.net
Lo último que nos pregunto es el nombre común (CN common name), aqui es sumamente importante indicarlo igual a como esta el certificado raíz generado previamente, como se trata de un servidor web, lo correcto es poner www.ostau.net
Lo anterior genera dos archivos:ostau-cert.pem = el certificate signing request (csr) key.pem = la llave privada
verifiquemos el contenido de la solictud:
#> more ostau-cert.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIBwTCCASoCAQAwRjETMBEGA1UEChMKUGF0bywgUy5BLjENMAsGA1UEBxMETGVv
bjETMBEGA1UECBMKR3VhbmFqdWF0bzELMAkGA1UEBhMCTVgwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMMvo7xg3vmdlf/38yA68uzNq2WYTtkyecuBnUgocOqD
gc0Yl2hrfXN6lHl65kxeRFVdEBYhGgA7JoISivuDTvWwVOIxmH5HOFzZlIPIZ3xT
hHCdWUKipXhcsVCTGV+rbB1F9kkIAMrmtaNH2+Zj261jdB7eX960l1EqQaWt71dJ
AgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYEFGVf
A/CDDXl6LQs1MH/XItqJl/8kMA0GCSqGSIb3DQEBBAUAA4GBAJH0sO7bR+dJL67p
xK5oEG9LPA2KcP+W7Vn5edpaLtUs/jYyvhQaCdSBxbMkV42nmt9DGD5p5caTFk3M
5guV9f087K+eYnUGILGQS51tXFcmYramZLETzs7nVfwGnXGsDGyKDkG6VTkx46pz
JrRTJfWBpWpo4FWg/Fi2l4E4PLv8
-----END CERTIFICATE REQUEST-----
Observa claramente que se trata de una solicitud de certificación (Certificate Request), es decir que tiene que ser firmado por una autoridad certificadora CA que somos nosotros mismos.

Por último firmaremos la solicitud que hicimos anteriormente para generar un certificado autofirmado, para firmarlo necesitaremos indicar la contraseña que autentifique que somos la CA y que por serlo tenemos la autoridad de autorizar (firmar) certificados. (Para nuestro propio uso)


#> openssl ca -out certificado-ostau.pem -config ./openssl.cnf -days 3650 -infiles ostau-cert.pem
Using configuration from ./openssl.cnf
Enter pass phrase for ./privado/cakey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
organizationName :PRINTABLE:'ostau, S.A.'
organizationalUnitName:PRINTABLE:'redes'
localityName :PRINTABLE:'Leon'
stateOrProvinceName :PRINTABLE:'Guanajuato'
countryName :PRINTABLE:'MX'
commonName :PRINTABLE:'www.ostau.net'
Certificate is to be certified until Jan 26 00:10:10 2016 GMT (3650 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
#>

Se comprueba que ya aumento el número de serie a 02, es decir, el siguiente certificado que firmemos será ese número.


#> more serial
02

En el archivo index.txt el tercer campo indica 01, que es el número de serie
para el certificado recien creado y muestra también los campos del DN.
#> more index.txt
V 160126001010Z 01 unknown /C=MX/ST=Guanajuato/O=ostau, S.A./OU=redes/
CN=www.ostau.net
En el directorio de certificados se guarda también con el correspondiente número de serie (01.pem) un archivo que complementa la base de datos de certificados que podemos ir creando.
#> ls -l certificados
total 4
-rw-r--r-- 1 root root 2597 ene 27 18:10 01.pem

Y por último tenemos el certificado en si:
#> ls -l certificado-ostau.pem
-rw-r--r-- 1 root root 2597 ene 27 18:10 certificado-ostau.pem

Y podemos inspeccionarlo:
#> openssl x509 -in certificado-ostau.pem -noout -text -purpose
Instalando el certificado y la llave para Apache
Tenemos entonces dos elementos ya generados que necesitaremos para Apache: key.pem = llave privada ; certificado-ostau.pem = certificado autofirmado
Hay algunas aplicaciones (no Apache) que requieren estos dos elementos en un solo archivo, como en el caso de stunnel:
# > cat key.pem certificado-ostau.pem > key-cert-ostau.pem
Simplemente se concatenan los dos archivos en uno. Pero esto no es necesario para el caso del servidor Web Apache. Lo que hay que hacer es copiar nuestros dos archivos en un directorio, de hecho podrían quedarse donde están, es lo de menos, pero por cuestión de orden y organización vamos a copiarlos a /etc/httpd/conf que en la mayoría de distribucciones es el directorio de configuración del Apache.
NOTA IMPORTANTE: por ningún motivo los copies dentro del directorio raíz del servicio de Apache como /var/www/html ya que podrías dejar expuestos los archivos a todo el mundo y ser vulnerados.
#> cp key.pem certificado-ostau.pem /etc/httpd/conf/.
Una vez copiados los archivos, hay que crear un servidor virtual en Apache, esto dentro del archivo de configuración httpd.conf, en algunas distribucciones como Fedora y otras dentro de /etc/httpd/conf.d hay un archivo llamado ssl.conf que es donde viene un servidor virtual ya creado, se puede tomar como plantilla.

VirtualHost 192.168.1.127:443
ServerName www.pato.com
DocumentRoot /var/www/consulta
... (demás directivas del sitio)
SSLEngine on
SSLCertificateFile /etc/httpd/conf/certificado-ostau.pem
SSLCertificateKeyFile /etc/httpd/conf/key.pem
VirtualHost

Como ya había mencionado antes, si quieres evitar que a tus clientes cada vez que ingresen a tu sitio salga el molesto diálogo que pide aceptar el certificado, la única solución es que distribuyas el archivo cacert.pem, recuerda que este archivo es el que te identifica como una autoridad certificadora. Lo puedes poner a descarga desde tu propio sitio, o mandarlo por correo, como sea. Cuando el cliente lo tenga en su equipo deberá importarlo dentro del browser o navegador. Todos los navegadores en sus preferencias o herramientas tienen una opción de certificados y desde ahí existe un botón importar para realizar esto.
Pues eso es todo, si todo funcionó bien, tienes ahora un sitio con encriptación de extremo a extremo y todo el tráfico viaja seguro. (sslv2)
sslv3
crear solicitud de firmado de certificado por otra AC

generamos la peticion y al clave dentro de /etc/ssl/CA

openssl req -new -out solicitudclient.pem -keyout privado/claveclient.pem -config ./openssl.cnf

firmar la peticion del cliente

openssl ca -out firmaclient.pem -config ./openssl.cnf -extensions v3_client -days 3650 -infiles solicitudclient.pem

pero antes agregamnos las siguientes lineas en /etc/ssl/CAopenssl.cnf

[ v3_client ]
basicContraints = CA:FALSE
extendedKeyUsage = ClientAuth

luego editamos /etc/apache2/sites-available/default

y agregamos

SSLCACertificateFile /etc/ssl/CA/cacert.pem
SSLVerifyClient require

ahora exportamos el certificado con un formato p12 para que el navegador lo reconosca

openssl pkcs -export -in firmaclient.pem -inkey privado/claveclient.pem -certfile cacert.pem -out cerclient.p12

Monday 23 February 2009

ssl

Secure Socket Layer es un sistema de protocolos de caracter general diseñado en 1994 por la empresa Nestcape Communcations Corporation, y está basado en la aplicación conjunta de Criptografía Simétrica, Criptografía Asimétrica (de llave pública), certificados digitales y firmas digitales para conseguir un canal o medio seguro de comunicación a través de Internet. De los sistemas criptográficos simétricos, motor principal de la encriptación de datos transferidos en la comunicación, se aprovecha la rapidez de operación, mientras que los sistemas asimétricos se usan para el intercambio seguro de las claves simétricas, consiguiendo con ello resolver el problema de la Confidencialidad en la transmisión de datos.

SSL implementa un protocolo de negociación para establecer una comunicaión segura a nivel de socked (nombre de máquina más puerto), de forma transparente al usuario y a las aplicaciones que lo usan.

La identidad del servidor web seguro (y a veces también del usuario cliente) se consigue mediante el Certificado Digital correspondiente, del que se comprueba su validez antes de iniciar el intercambio de datos sensibles (Autenticación), mientras que de la seguridad de Integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y la comprobación de resúmenes de todos los datos enviados y recibidos.

Desde el punto de vista de su implementación en los modelos de referencia OSI y TCP/IP, SSL se introduce como una especie de nivel o capa adicional, situada entre la capa de Aplicación y la capa de Transporte, sustituyendo los sockets del sistema operativo, lo que hace que sea independiente de la aplicación que lo utilice, y se implementa generalmente en el puerto 443.

La versión más actual de SSL es la 3.0. que usa los algoritmos simétricos de encriptación DES, TRIPLE DES, RC2, RC4 e IDEA, el asimétrico RSA, la función hash MD5 y el algoritmo de firma SHA-1

SSL proporciona cifrado de alto nivel de los datos intecambiados (se cifran incluso las cabeceras HTTP), autenticación del servidor (y si es necesario también del cliente) e integridad de los datos recibidos.

las páginas que proceden de un servidor SSL vienen implementadas mediante el protocolo HTTP seguro, y la direccion en el navegador siempre empezará por https , como por ejemplo:

https://mail.ostau.net

protocolo ssl handshake: Es uno de los posibles protocolos que pueden encapsularse sobre la capa anterior y permite al cliente y al servidor autenticarse mutuamente, negociar un algoritmo de cifrado e intercambiar llaves de acceso.


protocolo ssl record: Está ubicada sobre algún protocolo de transporte confiable (como por ejemplo TCP) y es usado para encapsular varios tipos de protocolos de mayor nivel.



SET se basa en el uso de certificados digitales para asegurar la perfecta identificación de todas aquellas partes que intervienen en una transacción on-line basada en el uso de tarjetas de pago, y en el uso de sistemas criptográficos de clave pública para proteger el envío de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso. Con ello se persigue mantener el caracter estrictamente confidencial de los datos, garantizar la integridad de los mismos y autenticar la legitimidad de las entidades o personas que participan en la transacción, creando así un protocolo estandar abierto para la industria que sirva de base a la expansión del comercio electrónico por Internet.

En febrero de 1996 un grupo de empresas del sector financiero, informático y de seguridad (Visa International, MasterCard, Microsoft, Nestcape, IBM, RSA, ect.) anunciaron el desarrollo de una nueva tecnología común destinada a proteger la compras a través de redes abiertas como Internet basadas en el uso de tarjetas de crédito. Esta nueva tecnología se conoce con el nombre de Secure Electronic Transatrions (Transacciones Electrónicas Seguras), SET, y ha sido creada exclusivamente para la realización de comercio electrónico usando tarjetas de crédito.

El proceso completo de pago mediante el protocolo SET puedes observarlo en el siguente grafico

El cliente, seleccion los artículos a comprar en el sitio web del vendedor, envía a éste un formulario de pedido, siendo respondido por el comerciante con el envío de su certificado digital y el de la pasarela de pago.

El cliente comprueba la validez de los certificados y envía entonces al comerciante una orden de pago, que está dividida en dos secciones o documentos diferentes: la Información de pedido (OI), en la que figuran los datos de los productos comprados, su precio y las demás informaciones necesarias para la compra, y la Instrucción de compra (PI), en donde se describen sus datos bancarios y se dan instrucciones para el pago a la entidad vendedora.

Esta orden de pago se firma digitalmente por medio de un algoritmo especial, denominado Firma Dual, que se realiza concatenando primero los resúmenes hash de los dos documentos generados y encriptándo esta concatenación después con su llave privada, para seguidamente encriptar la Firma Dual mediante una clave simétrica generada por su software SET. Por último, se encriptan la clave simétrica generada y el número de la trajeta de crédito con la llave pública de la pasarela de pago.

De esta forma el vendedor no puede conocer los datos bancarior del comprador, y el banco no puede conocer la información sobre los productos comprados, a pesar de que ambos documentos están ligados por la misma firma. En ciertos casos es posible realizar la transacción sin esta firma dual, estableciéndose mediante un protocolo inicial qué metodo se va a usar.

El vendedor recibe la orden de compra y la firma dual del ciente, se queda con la descripción de la compra y trás comprobar la auntenticidad del comprador, utilizando para ello la firma digital de éste y su certificado, y la integridad de los datos recibidos envía los datos financieros a la Pasarela de Pago encriptados con la clave pública de la misma.

La Pasarela de Pago comprueba la autenticidad del comprador y la integridad del PI del mismo, y con el mensaje del vendedor comprueba la relación existente entre la descripción de la compra enviada al vendedor y la usada para la firma dual recibida.

Si todo es correcto, la Pasarela de Pago envía mediante las redes de comunicación bancarias el PI al banco del vendedor y solicita autorización para realizar el pago, mediante un documento denominado Petición de autorización de pago.

El banco del vendedor comprueba entonces que la tarjeta de crédito es válida y permite el cargo del importe de la compra, enviando entonces un documento a la pasarela, denominado Autorización de pago, que autoriza el proceso de compra.

Una vez informado el vendedor de la autorización procede al envío de los artículos comprados al cliente, y después de la entrega física del producto pide el importe de la venta a la Pasarela de Pagos, proceso que se conoce con el nombre de Solicitud de pago.

Entonces la Pasarela de Pagos pide al banco del comprador la transferencia del importe de la venta al banco del vendedor, petición que recibe el nombre de Solicitud de compensación. Entonces se le hace efectivo al vendedor el importe, con lo que se cierra el proceso total de compra.

Todos los documentos implicados en el proceso anterior deben llevar un número identificador único de transacción, conocido como ID.