CLICK HERE FOR BLOGGER TEMPLATES AND MYSPACE LAYOUTS »
http://www.yaves.eshttp://www.yaves.eshttp://www.yaves.eshttp://www.yaves.eshttp://www.yaves.es

martes, 17 de febrero de 2009

SSL

SSL2_WINDOWS

lunes, 9 de febrero de 2009

SSH Secure SHell

Es un protocolo que facilita las comunicaciones seguras entre dos sistemas utilizando la arquitectura de cliente/servidor y permite la conexion remota. SSH encripta la sesion de conexiones, haciendo impoible que alguien pueda obtener contraseñas no encriptadas. Es el remplazo de motedos mas viejos e inseguros para las conexiones remotas por medio de la shell de comandos como lo es el telnet. Se utiliza SSH para inicios de sesion remota y para copiar archivos, con la diferencia que de los demas que estepermite disminuir la amenazas a la seguridad, eso porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad y la comunicacion es encriptada; por ende los intrusos perderan su tiempo al intetar falsificar o analizar informacion porque cada paquete esta cifrado por medio de una llave conocida solo por el sistema local y remoto.

CONFIGURACION DE SSH EN WINDOWS SERVER 2003

Lo primero que hacemos es instalar el OpenSSH. Lo puedes descargar del siguiente link http://openssh.softonic.com/.

Para iniciar la configuracion nos dirigimos al simbolo del sistema (cmd) e inmgresamos a a siguiente ruta "\Archivos de programas\OpenSSH\bin"y creamos el archivo "passwd" donde agregaremos a los usuarios que se le autoriza la comunicacion por el SSH, los usuarios que se ingresen en este archivo tienen que esxistir en el sistema. Para los usuarios locales se agregan con -l y para usuarios que pertenezcan a un dominion se agregan con -d.



NOTA: con "mkpasswd" creamos el archivo, el "Administrador" hace referencia al usuario que tengo en el sistema; las ">>" es la redireccion al archivo, y "\etc\passwd" es la ruta donde se guarda el archivo.

De la misma manera creamos el archivo group que es para los permisos.



Ahora configuramos la variable de entorno parth: INICIO --> clic seccundario en MIPC --> PROPIEDADES y nos se abre la ventana de "propiedads del sistema" y nos dirigimos a la pestaña "opciones avanzadas" y luego en la opcion "variable de entorno"



Se inicia uan nueva ventana "variables de entorno" donde en el campo "variables del sistema" buscamo y selecionamos el "path" y damos clic en la opcion "modificar"



En el campo del valor de la variable colocamos al final la ruta del "bin" de OpenSSh y damos aceptar.



Regresamos a la ventana de variables de entorno automaticamente y ahaora damos en la opcion "nuevo" y creamos la variable HOME en el campo "nombre de la variable" y en el campo "valor de la variable" se ingresa la ruta de Openssh.



Con esto terminamos la configuracion del OpenSSH en nuestro sistema,ahora iniciaremos a configurar de todo lo requerido para la autenticacion de llaves.Iniciaremos con la creacion de nuetro para de llaves privada/publica, la cual de genera con "ssh-keygen" el cual se crea por defecto en la siguiente ruta "Documents and settings\Administrador\.ssh" y como el directorio ".ssh" no existe al crear las claves este proceso lo crea automaticamente.



Nos dirigimos a al directorio donde creamos las llaves en nuestro caso es el directorio "Documents and settings\Administrador\.ssh" y verificamos si alli estan almacenado los siguientes archivos:
ID_DSA --> Archivo donde se encuentra la llave privada
ID_DSA.PUB --> Archivo donde se encuentra la llave publica
KNOWN_HOSTS --> Archivo donde se almacena todas la autenticaciones realizadas es recomendable que este archivo se encuentre vacion cuando estemos realizando autenticaciones porque este puede presentar problema a la hora de la conexion.



Ahora creamos es archivo "authorized_keys" que es el archivo donde se ingresaran todas las llaves publicas de los clientes para su debida autenticacion. Este archivos por defecto se crea en el directorio .ssh pero nosotros lo crearemos en el etc del OpenSSh y debemos de tener mucho cuidado al poner la ruta en el archivo de configuracion.



Ya creado unos de los archivos mas importantes para esta configuracion "authorized_keys" el paso a seguir es enviar nuestra llave purblica a este archivo, es decira, redireccionar el archivo "id_dsa.pub" que esta en la el directorio "Documents and settings\Administrador\.ssh" al archivo "authorized_keys" que se encuentra en el directori "archivos de programas\OpenSSH\etc", esto es para permitir al servidor la auteticacion por llaves publicas.



Y visualizamos el archivo authorized_keys y este nos mostrara nuestra llave publica:



El siguiente paso es configurar el archivo "sshd_config" ubicado en "archivos de programas\OpenSSH\etc" es en este archivo donde definimos toda la configuracion necesaria para que nuestro servidor autentifique con llaves publicas. la configuracion es la siguiente:

# $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

Port 22
#Protocol 2,1
Protocol 2
ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 1h
ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes

# The following setting overrides permission checks on host key files
# and directories. For security reasons set this to "yes" when running
# NT/W2K, NTFS and CYGWIN=ntsec.
StrictModes no

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /etc/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 10:30:60

# default banner path
Banner /etc/banner.txt

# override default of no subsystems
Subsystem sftp /usr/sbin/sftp-server

Despues de configurar el archivo iniciamos el servidor.



Con esto terminamos la configuracion ahora vamos hacer las practicas correspondientes. Entonces como buenos practicantes lo vamos a realizar primeramente en el equipo local.



Y efectivamente nos pide la clave publica de la llave que ingresamos en el archivo "authorized_keys", al ingresarla nos muestra la fecha, hora y nombre de nuestro equipo.

Para la pruba de linux a windows primero debo de ingresar la clave publica del cliente linux la cual fue mandada por scp desde linux.



Nos dirigimos a "documents and settings\Administrador" y alli encontraremos el archivos que nos enviaron.



Redireccionamos la llave al archivo "authorized_keys" para que este cliente pueda auteticar.



Si miramos el contenido del archivo authorized_keys podremos ver que ya no solo esta la llave de nuestro servidor sino que tambien la de nuestro cliente en linux.



Para finalizar reiniciamos el equipo y hacemos la prueba desde nuestro cliente linux, que nos deberia pedir su llave publica.



Y efectivamente nos funciona.

Para ver la configuracion SSH en linux de clic en el siguiente link http://lamatrix55.blogspot.com/2009/02/openssh.html

lunes, 2 de febrero de 2009

INFRAESTRUCTURA DE CLAVES PUBLICA (PKI)

Es la combinacion de software, tecnologias de encriptacion y servicios que posibilitan a las empresas u organismos otorga a sus comunicaciones y transacciones por internet.

  • el proposito es proveer claves y manejos de certificados confiables y eficientes para lograr la habilitacion de la autenticacion, la no repudio y la confidencialidad
  • logra la confianza basada en el uso de certificados de clave publica los cuales son estructuras de datos que ñigan valores de clave publica a los sujetos.
  • la ligadura se realiza a traves de una autoridad de certificacion, la cual verifica la identidad del sujeto y firma digitalmente el certificado.
paki garantiza a los documentos:
  • la identidad/autoridad
  • la confidencialidad
  • la integridad
  • no repudio
  • fecha y hora cierta de la firma "secure time stamp"
  • disponibilidad legitima de servicios de informacion
COMPONENTES DE LA ARQUITECTURA DE LLAVE PUBLICA (PKI)

1. LA INFRAESTRUCTURA DE LLAVE PUBLICA (PKI):

Es la integracion de:
  • La criptologia de llave publica o asimetrica
  • La criptologia de la llave privada o simetrica
  • El messege digest value o hash
2. EL MODELO PKIX:

Es el modelo de las entidades que gestionan la infraestructura de llave publica, designando sus funciones y protocolos.
  1. Entidades Finales: (a quien se pretende verificar):
  • el sujeto de un certificado, su identidad es garantizada por una autoridad de certificacion.
  • estas pueden se un usuarios finales, la autoridad de registros respecto a la autoridad de certificacion en el nombre de quien actua o incluso una autoridad de certificacion cuando esta se ce certificada por otra autridad de certificacion
2. Autoridad de certificado (CA):
  • representa la fuente de credibilidad de la infraestructura de llave publica
  • quienes emiten los certificados, firmandolos digitlamente con su llave privada
  • certifican que la llave publica asignada en un certificado a una entidad final, correspondiente realmente a dicha entidad final
3. Autoridad de Registro o Registration Authority (RA)
  • realiza el proceso de resgitro de las entidades finales por encargo de la autoridad de certificacion
  • valida los atributos del sujeto que solicita el certificado
  • verifica que el sujeto posee la llave privada a registrar
  • genera los secretos compartidos que permiten el proceso de inicializacion y certificacion
  • genera el par de llaves publico/privada
  • valida los parametros de las llaves publico prestados para su registro.
4. Repositorios o Repositories:
  • permite guardar informacion sobre PKI como puedan ser certificados y CRLs para su acceso por parte de las entidades finales o de sus delegados.
5. Emisores de CRLs o Certificate Revocation List Issuers:
  • los emisores de listas de revocacion de certificado actuan en nombre de la autoridad de certificacion, siendo de caracter opcional aunque sumamente convenientes. Son listas de los certificados que han dejado de ser validos y por tanto en los que se pueden confiar. Estos son revocados en caso como; la llave privada se vea comprometida o hayan cambiado los atributos del certificado.
PROCEDIMIENTO DE LA CERTIFICACION:
El objetivo del proceso de certificacion es garantizar la identidad de la entidad final, y con ella la identidad de las comunicaciones digitales.
  1. solicitud a la Autoridad de Certificado de un certificado por parte de la entidad final, a traves de la Autoridad de registro, con el objetivo de que la autoridad de certificacion garantice la identidad de la entidad final.
  2. la autoridad de certificado comprueba que cada usuario es quien dice ser y que la clave publica que inscriba en el certificado realmente le pertenece.
  3. el certificado de la entidad final se firma digitalmente cifrandolo con la llave privada de la autoridad de certificacion
  4. a su vez la autoridad de certificacion es certificada por otras autoridad/es de certificacion
  5. dicho certificado se destribuye globalmente, es decir, al mayor numero de destinatarios posibles.
CERTIFICADOS DIGITALES:
Son documentos que confirman la identidad de una persona fisica o juridica, vinculada con una llave publica asociada al llave privada. Tiene 2 aspectos como objeto:
  1. Que la llave publica del suscriptor pueda ser accesible por los verificadores o participes en validar y verificar la firma digital del suscriptor.
  2. Que los partcipes puedan confiar en que la lleve publica que recibe el verificador sea realmente la del suscriptor.
Los siguientes son los campos principales incluidos como contenido de un certificado de llave publica
  • identificador unico o Nº de serie del certificado
  • el algoritmo de firma digital empleada
  • datos de la autoridad de certificacion ID unico del emisor de certificados
  • fecha de expedicion y expiracion de la llave publica y privada
  • llave publica del titular del certificado.
CADENA DE CERTIFICACION:

Una Autoridad de certificacion puede a su vez estar certificada por otra/s, Autoridades de certificacion, con su firma digital, hasta llegar a la Autridad de certificacion Raiz , lo que conforma la "cadena de certificados" o "certification path" de cualquier certificado hasta su "Anclaje de Vercidad" o "Trust Anchor", que termina en el certificado Raiz de la autoridad de certificacion Raiz. Dicho certificado Raiz es un certificado asi mismo, y emitido por la Autoridad de Certificacion Raiz.

TIPOS DE CERTIFICADOS DIGITALES:
  • Certificado de clase 1: son emitido unicamente a individuos. no verifican la identidad del individuo y por ende no permite autenticar, confirma que el nombre o seudonimo y el sujeto del certificado forman un nombre de sijeto inequivoco.
  • Certificado de clase 2:son emitidos unicamente al individuo, confirma que la informacion proporcionada por el suscriptor no entra en conflicto con la informacion de las bases de datos fiables propiedad de una EE (Entidad de Emision) o una ERL (Entidad de Registro Local), incluida la identidad del sujeto y otros datos del suscriptor.
  • Certificado de clase 2 no reconocido (clase 2 tipo1):usada para transaciones de bajo riesgo
  • Certificado de clase 2 reconocido (clase 2 tipo 2): se pueden usar como soporte de firmas electronicas legalmente reconocidas, obtienen una razonable seguridad de la identidad de suscriptor comparando automaticamente el nombre del solicitante, direccion yotra informacion personal contenida en las bases de datos propiedad de l EE o ERL.
  • Certificado de clase 3, se emiten a:
  • Individuos: requiere la presentacion de evidencias probatorias de la identidad del sujeto personandose ante una ERL o su delegado
  • Organizaciones: se emiten a individuos con capacidad de firmar dentro una organizacion, probada esta capacidad de forma por evidencia natarial y de la propia organizacion a traves de organizaciones empresariales que confirmen su identidad.
3. LAS POLITICAS Y PRACTICAS DE CERTIFICACION CPS Y CP:

  • Declaracion de Practicas de Certificacion (CPS): describe las practicas empleads en la emision y gestion de certificados. Gobierna la gestion de la infraestructura de llaves publicas y podria tambien incluir las descripciones de los servicios ofrecidos. Provee de un marco legal que describe las obligaciones y margenes de responsabilidad que asume la Autoridad de certificacion, asi como sus derechos con los titulares de los certificados emitidos por esta.
  • Politica de Certificacion (CP): consiste en un conjunto de reaglas que indican la aplicabilidad de un certificado a una particular comunidad y lo de aplicaiones con requerimientos de seguridad comunes.
SOLUCIONES COMERCIALES DE PKI EN COLOMBIA:

CERTICAMARA:
es la primera entidad certificadora digital abierta, creada por las camaras de comercio del pais, esta vigilada y autorizada por la Superintendencia de Industria y Comercio, cumple con los mas altos estandares internacionales exigidos por el America Institute of Certificied Public Accountants (AICPA) y el Canadian Institute of Chartered Accountants (CISA), por esta razon posee el sello WEB TRUST, que la califica como entidad de certificacion de categoria y clase mundial, lo que ha permitido que Microsoft incluya a Certicamara dentro de las entidade de certificacion que son reconocidas automaticamente por el navegardo Internet Explorer. Los principales beneficios de Certicamara son:
  • Brinda seguridad en las transacciones que e realiza por medios electronicos
  • Proporciona soluciones a la empresa de materia de implementacion y utilizacion de nuevas tecnologias
  • Contribuir a la competitividad de las empresas y su participacion en la nueva economia
  • Contribuir al desarrolla y crecimiento de los negocios electronicos del pais, con estandares de seguridad que permitan el crecimiento de los negocios internacionales



ESQUEMA_PKI
Publish at Scribd or explore others:


NETGRAFIA DIBUJOS DEL ESQUEMA

http://office.microsoft.com/es-es/clipart/results.aspx?CategoryID=CM790019673082