Como era de esperarse empezamos a hacer unos trabajos y laboratorios en debian, todos sobre firewall; Todo muy bien hasta que empezamos a hacer las pruebas, al parecer el hecho de que tuvieramos maquinas virtuales, nos saco muchos errores.
Esto nos llevo a instalar maquinas reales, pero al momento de hacer la instalacion no monto la targeta inalambrica del portatil, esto me llevo a investigar y encontre una ayuda buenisima.
Para esta instalacion siempre tendras que estar como usuario root.
Lo primero que tenemos que hacer es mirar nuestro kernel
# uname -r ...............para mirar el kernel
Bueno instalamos
# apt-get build-essentials
Cuando obtengamos la informacion seguimos con:
# apt-get install linux-headers-2.6.26-1-686 Aqui coloca su No de kernel.
Despues de hecho todo esto miramos la targeta de red que tenemos.
# lspci .............. Con este comando listamos nuestros dispositivos.
En mi caso me salio esta linea.
03:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
Buscamos el paquete aqui.
Luego de descargado lo descomprimimos
# tar -zxvf madwifi-hal-0.10.5.6-current.tar.gz
Luego ingresamos a la carpeta.
cd madwifi-hal-0.10.5.6-r3942-20090205
# make
# makeinstall
Luego de instalado seguimos.
# sudo modprobe ath_pci
Ahora ponemos
# gedit /etc/modules
Y nos abrira un archivo de Texto al final agregamos esto
#inicia configuracion de wireless
ath_pci
#finaliza configuracion de wireless
Guardamos y cerramos
# ifconfig ath0 up
(Si este comando te da algún error solo reinicia la PC con eso bastara)
LISTO ESO ES TODO
Esta configuracion fue gracias a waytron30 en http://www.warianoz.com/foros/showthread.php?t=187931
MAURICIO ORTIZ
Instructor Sena
miércoles, 25 de marzo de 2009
domingo, 22 de marzo de 2009
Instalacion de IPsec en Debian Lenny
Este es un paso a paso de la instalacion de IPsec en Debian Lenny, con autenticacion de llaves manuales y automaticas, trabajando con los protocolos AH, ESP y RACOON, este ultimo con llaves precompartidas y certificados digitales.
Haga click Aqui. para ver el video tutorial.
Haga click Aqui. para ver el video tutorial.
viernes, 27 de febrero de 2009
jueves, 26 de febrero de 2009
Configuracion GPG en Debian Etch
GPG o GNU Privacy Guard es una herramienta para cifrado y firmas digitales, que viene a ser un reemplazo del PGP (Pretty Good Privacy) pero con la principal diferencia que es software libre licenciado bajo la GPL. GPG utiliza el estándar del IETF denominado OpenPGP.
GPG es estable, calificado como un software para el uso en producción y es comúnmente incluido en los sistemas operativos como FreeBSD, OpenBSD, NetBSD y últimamente con todas las distribuciones GNU/Linux.
Aunque básicamente el programa tiene una interfaz textual, actualmente hay varias aplicaciones gráficas que utilizan recursos de GPG. Por ejemplo, ha sido integrado dentro de Kmail y Evolution, también hay un plugin llamado Enigmail que se integra con Mozilla y Thunderbird que trabajan en Windows, GNU/Linux y otros sistemas operativos.
Comenzaremos con la instalacion de los paquetes para su desarrolllo en debian.
Luego de instalado el programa, procedemos a crear la llaves nuestras.
Cuando empezamos con la creacion nos comienzan a salir una serie de preguntas que veremos a continuacion.
Una de ellas es el tipo de de firma y cifrado, la cual la rea la primera opcion, que haria ambas "firmar y cifrar", si nuestra necesidad solo es firmar, podemos escojer la opcion dos y tres.
En este nos esta preguntando el tiempo de vigencia que le queremos dar a la llave.
Luego vamos con nuestros datos, que van a quedar como identificador de la llave.
En estos estara nuestro nombre y apellido, correo, y un tipo de comentario
sobre esta llave.
Por ultimo tiene que salir algo como esto al terminar de crearla.
Para comprobar nuestra creacion, le damos el comnado de listar las llaves
y saldra el identificador y los datos anexados en el momento de la creacion.
Para listar la llave privada, introducimos este comando gpg --list-secret-key
Ahora poedemos guardar nuestra llave en un archivo .txt, esto nos servira en el caso
de que la queramos guardar en un lugar seguro o la queramos enviar cifrada a otra persona por otro medio diferente al de un servidor.
Por seguridad y comodidad de tener la llave privada, la podemos exportar de forma que queramos trabajar en otro equipo, o solo queramos tener un backup de ella.
En le archivo .txt les debe aparecer algo similar a esta imagen.
En el caso de que tengamos una llave vencida o se encuentre obsoleta por "X" motivo
la podemos revocar de las siguientes formas.
Primero tenemos que revocar la llave privada asi.
Luego borramos la llave publica.
Es de tener en cuenta que si no borramos la privada primero no podremos eliminar
la llave publica.
Si queremos ver la huella de la llave, en el caso que queramos asegurarnos de
la misma, le damos de esta forma.
Luego de haber ingresado a un servidor por modo web, descargue una llave, la cual copie y guarde en un archivo de texto.
Para importarla es necesario pararnos en el directorio donde esta la llave o solamente le damos toda la ruta, a continuacion mostrare el comando de importacion.
Cuando queremos baja una llave de un servidor "x" en este caso lo haremos de rediris automaticamnete nuestra llave queda en sistema de trabajo de GNUPG.
Ahoras vamos a enviar nuestra llave al servidor via consola.
Puedo crear un anillo de confianza con las claves de mi circulo, firmando las llaves almacenadas
en mi equipo y que son de mi entera confianza, asi cuando otra persona del circulo la vea firmada por mi, tenga la entera confianza sobre esa llave, asi de igual forma yo puedo ver otras llaves firmadas por otro que sea de mi confianza.
Este es el comando con el cual yo voy a firmar las llaves.
Luego de dar el comando para firmar la llave el sistema te pedira la confirmacion de querer firmar la llave, y luego te solicita la contraseña de tu gpg.
Ya firmada la llave lo puedes comprobar con el comando #gpg --check-sigs.
GPG es estable, calificado como un software para el uso en producción y es comúnmente incluido en los sistemas operativos como FreeBSD, OpenBSD, NetBSD y últimamente con todas las distribuciones GNU/Linux.
Aunque básicamente el programa tiene una interfaz textual, actualmente hay varias aplicaciones gráficas que utilizan recursos de GPG. Por ejemplo, ha sido integrado dentro de Kmail y Evolution, también hay un plugin llamado Enigmail que se integra con Mozilla y Thunderbird que trabajan en Windows, GNU/Linux y otros sistemas operativos.
Comenzaremos con la instalacion de los paquetes para su desarrolllo en debian.
Luego de instalado el programa, procedemos a crear la llaves nuestras.
Cuando empezamos con la creacion nos comienzan a salir una serie de preguntas que veremos a continuacion.
Una de ellas es el tipo de de firma y cifrado, la cual la rea la primera opcion, que haria ambas "firmar y cifrar", si nuestra necesidad solo es firmar, podemos escojer la opcion dos y tres.
En este nos esta preguntando el tiempo de vigencia que le queremos dar a la llave.
Luego vamos con nuestros datos, que van a quedar como identificador de la llave.
En estos estara nuestro nombre y apellido, correo, y un tipo de comentario
sobre esta llave.
Por ultimo tiene que salir algo como esto al terminar de crearla.
Para comprobar nuestra creacion, le damos el comnado de listar las llaves
y saldra el identificador y los datos anexados en el momento de la creacion.
Para listar la llave privada, introducimos este comando gpg --list-secret-key
Ahora poedemos guardar nuestra llave en un archivo .txt, esto nos servira en el caso
de que la queramos guardar en un lugar seguro o la queramos enviar cifrada a otra persona por otro medio diferente al de un servidor.
Por seguridad y comodidad de tener la llave privada, la podemos exportar de forma que queramos trabajar en otro equipo, o solo queramos tener un backup de ella.
En le archivo .txt les debe aparecer algo similar a esta imagen.
En el caso de que tengamos una llave vencida o se encuentre obsoleta por "X" motivola podemos revocar de las siguientes formas.
Primero tenemos que revocar la llave privada asi.
Luego borramos la llave publica.
Es de tener en cuenta que si no borramos la privada primero no podremos eliminar
la llave publica.
Si queremos ver la huella de la llave, en el caso que queramos asegurarnos de
la misma, le damos de esta forma.
Luego de haber ingresado a un servidor por modo web, descargue una llave, la cual copie y guarde en un archivo de texto.
Para importarla es necesario pararnos en el directorio donde esta la llave o solamente le damos toda la ruta, a continuacion mostrare el comando de importacion.
Cuando queremos baja una llave de un servidor "x" en este caso lo haremos de rediris automaticamnete nuestra llave queda en sistema de trabajo de GNUPG.
Ahoras vamos a enviar nuestra llave al servidor via consola.
Puedo crear un anillo de confianza con las claves de mi circulo, firmando las llaves almacenadas
en mi equipo y que son de mi entera confianza, asi cuando otra persona del circulo la vea firmada por mi, tenga la entera confianza sobre esa llave, asi de igual forma yo puedo ver otras llaves firmadas por otro que sea de mi confianza.
Este es el comando con el cual yo voy a firmar las llaves.
Luego de dar el comando para firmar la llave el sistema te pedira la confirmacion de querer firmar la llave, y luego te solicita la contraseña de tu gpg.
Ya firmada la llave lo puedes comprobar con el comando #gpg --check-sigs.
domingo, 8 de febrero de 2009
OpenSSH
Esta es una pequeña introduccion de la instalacion y configuracion del OpenSSH
en Debian lenny.
Empezamos con la instalacion de los dos paquetes necesarios para nuestra configuracion.
Como esta es una version de Debian muy nueva les voy a colocar una linea de repositorio que me ha funcionado muy bien deb http://ftp.de.debian.org/debian lenny main.
En la imagen anterior se muestra la linea que utilizamos para instalar nuestro servidor SSH; seguida de la imagen con la cual montamos el cliente SSH.
Como ya hemos instalado los paquetes vamos a crear una llave la cual vamos a enviar al servidor ssh; para conectarnos sin que solicite password de root, si no de nuestra llave.Cabe recordar que nosotros somos clientes y servidores. En algun momento alguien nos enviara su llave para poderse conectar de la misma forma con nosotros.
En el momento de la creacion de la llave el sistema te va a preguntar por una frase o password; Coloca una que te sea facil de recordar.
Ya creada la llave vamos a crear el archivo en donde vamos a introducir las llaves de los usuarios de nuestro servidor, esta ruta esta ubicada en el archivo #> etc/ssh/sshd_config en el viene en la configuracion del SSH, cuando vean el archivo, encontraran una ruta que es la que especifica donde tiene que leer para encontrar la llave de las autorizaciones #> root/.ssh/authorize_keys, este archivo no existe entonces lo creamos como se ve en la imagen de abajo.
Ahora nos vamos a configurar nuestro servidor.
Ahora dejo una pequeña muestra de como se configura el ssh, con una breve explicacion de algunas lineas.
Siginificado de algunas lineas del ssh/sshd_config
RECUERDEN ESTA ES UNA CONFIGURACION PERSONALIZADA. PARA TU NECESIDADES PUEDES TENER OTRA, ESTA ES UNA BASE DE LO QUE SIGNIFICAN ALGUNAS LINEAS.
# Definimos el puerto por el que escuchamos las peticiones de conexión del los clientes
Port 22
# Especificamos por qué direcciones locales escucharemos.
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
# Especificamos las versiones del protocolo que aceptaremos
Protocol 2,1
# Archivos que contienen las llaves privadas de host a usar (solo permisos rw- para root)
# HostKeys for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Cada cuantos segundos el servidor regenera las claves, para así evitar el que se puedan
# descifrar sesiones caputaradas y luego usarse. Nunca es guardada en disco.
KeyRegenerationInterval 3600
# Espeficia el nº de bits para la clave del servidor del protocolo v1
ServerKeyBits 768
# Tipo de logeo de actividades -> AUTH=>/var/log/auth.log También disponible DAEMON, USER...
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
# El servidor desconecta al cliente si no se ha logueado correctamente en 600 segs.
LoginGraceTime 600
# Permitimos o no el login del usuario root => poner a no!
PermitRootLogin no
# SSH comprobará que los archivos tienen los permisos correctos, para evitar tener archivos con todos
# los permisos a todos los usuarios
StrictModes yes
# Permitimos la autentificación por RSA (solo para v1)
RSAAuthentication yes
# Permitimos la autentificación por clave pública (solo para v2)
PubkeyAuthentication yes
# Contiene el archivo que contiene las claves para la autentificación
#AuthorizedKeysFile %h/.ssh/authorized_keys
# NO usaremos el método de autentificación por rhost (.rhost)
# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# No usamos el protocolo de autentificación por host
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# HAbilitamos la autentificación "normal" si todo falla
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user
PAMAuthenticationViaKbdInt yes
# Opciones para servidor Kerberos
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
# En un principio, no permitimos exportar las X
X11Forwarding no
# Espeficicamos el primer nº de pantalla disponible para exportar
X11DisplayOffset 10
# Si queremos que al hacer login, al usuario le salga /etc/motd
PrintMotd no
# Por defecto, enseñaremos los datos del último login
#PrintLastLog no
# Para que el servidor pueda "enterarse" de que el cliente ha caido por ej
KeepAlive yes
#
#UseLogin no
#MaxStartups 10:30:60
# Si queremos enviar un banner cuando un cliente se conecte
#Banner /etc/issue.net
#ReverseMappingCheck yes
# Servidor ftp por ssh
Subsystem sftp /usr/lib/sftp-server
Luego de haber organizado nuestra configuracion, procedemos a enviar nuestra llave que se encuentra en la ruta #> root/.ssh/id_rsa.pub, en la imagen a continuacion se mustra el archivo en el Deskto, por que yo lo habia copiado en esa ruta.
Ahora voy a enviar mi llave a otro servidor.
De igual forma con el mismo comando sea desde un equipo linux o windows nos pueden enviar la llave.
Bibliografia
http://www.e-ghost.deusto.es/docs/TutorialOpenSSH.html
Maurio Ortiz Morales
Tutor Admon de Redes de Computadores
Centro de Servicios SENA Medellin.
en Debian lenny.
Empezamos con la instalacion de los dos paquetes necesarios para nuestra configuracion.
Como esta es una version de Debian muy nueva les voy a colocar una linea de repositorio que me ha funcionado muy bien deb http://ftp.de.debian.org/debian lenny main.
En la imagen anterior se muestra la linea que utilizamos para instalar nuestro servidor SSH; seguida de la imagen con la cual montamos el cliente SSH.
Como ya hemos instalado los paquetes vamos a crear una llave la cual vamos a enviar al servidor ssh; para conectarnos sin que solicite password de root, si no de nuestra llave.Cabe recordar que nosotros somos clientes y servidores. En algun momento alguien nos enviara su llave para poderse conectar de la misma forma con nosotros.
En el momento de la creacion de la llave el sistema te va a preguntar por una frase o password; Coloca una que te sea facil de recordar.
Ya creada la llave vamos a crear el archivo en donde vamos a introducir las llaves de los usuarios de nuestro servidor, esta ruta esta ubicada en el archivo #> etc/ssh/sshd_config en el viene en la configuracion del SSH, cuando vean el archivo, encontraran una ruta que es la que especifica donde tiene que leer para encontrar la llave de las autorizaciones #> root/.ssh/authorize_keys, este archivo no existe entonces lo creamos como se ve en la imagen de abajo.
Ahora nos vamos a configurar nuestro servidor.
Ahora dejo una pequeña muestra de como se configura el ssh, con una breve explicacion de algunas lineas.
Siginificado de algunas lineas del ssh/sshd_config
RECUERDEN ESTA ES UNA CONFIGURACION PERSONALIZADA. PARA TU NECESIDADES PUEDES TENER OTRA, ESTA ES UNA BASE DE LO QUE SIGNIFICAN ALGUNAS LINEAS.
# Definimos el puerto por el que escuchamos las peticiones de conexión del los clientes
Port 22
# Especificamos por qué direcciones locales escucharemos.
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
# Especificamos las versiones del protocolo que aceptaremos
Protocol 2,1
# Archivos que contienen las llaves privadas de host a usar (solo permisos rw- para root)
# HostKeys for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Cada cuantos segundos el servidor regenera las claves, para así evitar el que se puedan
# descifrar sesiones caputaradas y luego usarse. Nunca es guardada en disco.
KeyRegenerationInterval 3600
# Espeficia el nº de bits para la clave del servidor del protocolo v1
ServerKeyBits 768
# Tipo de logeo de actividades -> AUTH=>/var/log/auth.log También disponible DAEMON, USER...
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
# El servidor desconecta al cliente si no se ha logueado correctamente en 600 segs.
LoginGraceTime 600
# Permitimos o no el login del usuario root => poner a no!
PermitRootLogin no
# SSH comprobará que los archivos tienen los permisos correctos, para evitar tener archivos con todos
# los permisos a todos los usuarios
StrictModes yes
# Permitimos la autentificación por RSA (solo para v1)
RSAAuthentication yes
# Permitimos la autentificación por clave pública (solo para v2)
PubkeyAuthentication yes
# Contiene el archivo que contiene las claves para la autentificación
#AuthorizedKeysFile %h/.ssh/authorized_keys
# NO usaremos el método de autentificación por rhost (.rhost)
# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# No usamos el protocolo de autentificación por host
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# HAbilitamos la autentificación "normal" si todo falla
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user
PAMAuthenticationViaKbdInt yes
# Opciones para servidor Kerberos
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
# En un principio, no permitimos exportar las X
X11Forwarding no
# Espeficicamos el primer nº de pantalla disponible para exportar
X11DisplayOffset 10
# Si queremos que al hacer login, al usuario le salga /etc/motd
PrintMotd no
# Por defecto, enseñaremos los datos del último login
#PrintLastLog no
# Para que el servidor pueda "enterarse" de que el cliente ha caido por ej
KeepAlive yes
#
#UseLogin no
#MaxStartups 10:30:60
# Si queremos enviar un banner cuando un cliente se conecte
#Banner /etc/issue.net
#ReverseMappingCheck yes
# Servidor ftp por ssh
Subsystem sftp /usr/lib/sftp-server
Luego de haber organizado nuestra configuracion, procedemos a enviar nuestra llave que se encuentra en la ruta #> root/.ssh/id_rsa.pub, en la imagen a continuacion se mustra el archivo en el Deskto, por que yo lo habia copiado en esa ruta.
Ahora voy a enviar mi llave a otro servidor.
De igual forma con el mismo comando sea desde un equipo linux o windows nos pueden enviar la llave.
Bibliografia
http://www.e-ghost.deusto.es/docs/TutorialOpenSSH.html
Maurio Ortiz Morales
Tutor Admon de Redes de Computadores
Centro de Servicios SENA Medellin.
Esquema PKI
El acrónimo PKI deriva de "Public Key Infrastructure" (Infraestructura de Clave Pública) y es la forma común de referirse a un sistema complejo necesario para la gestión de certificados digitales y aplicaciones de la Firma Digital.
Una PKI bien construida debe tener una arquitectura proporcionar a:
• Autenticidad. La firma digital tendrá la misma validez que la manuscrita.
• Confidencialidad, de la información transmitida entre las partes.
• Integridad. Debe asegurarse la capacidad de detectar si un documento
firmado ha sido manipulado.
• No Repudio, de un documento firmado digitalmente.
Su arquitectura seria:
1. La infraestructura de llave publica o PKI
2. El modelo PKIX, o modelo de las entidades que gestionan la infraestructura de llave publica, degsinando funciones y protocolos.
3. Las politicas y praticas de certificacion CPS y CP.
La arquitectura PKI se encuentra: Internet Certificate and CRL Profile RFC 3280
> Especificada Internet Engineering Task Forge. http://ietf.org
El Modelo PKIX
En la imagen que veran a continuacion, el usuario va a acceder a una pagina de una entidad bancaria, con la cual requiere tener un canal de comunicacion seguro.
Primero abre su browser o navegador y digita la direccion web del banco, la cual hace una serie de peticiones para enviar el certificado al usuario firmado por una autoridad de certificadora ya reconocida y dar tranquilidad sobre la autenticidad de la identidad del banco.
Contiene 5 componentes
1. Entidades Finales: Quien solicita la llave o se pretende identificar
2. Autoridad de Certificacion: La que emite los certificados y es la parte de la credibilidad de la llave publica. Firma los certificados con su llave privada, dando fe de que es en la verificacion de las llaves asignadas son a quien corresponde.
3. Autoridad de Registro: Realiza el proceso de registro de las entidades finales, validad los atributos, genera los secretos compartidos que permiten el proceso de inicializacion y certificacion.
4. Repositorios: Metodo que permite guardar la informacion de PKI "Certificados y CRL", viendo tambien el status de revocacion de los certificados.
5. Emisores CRLs "Certificate Revocation List Issuer":Son listas de certificados que han dejado de ser validos.
Contenido del Certificado.
Es necesario poder vincular la clave pública de un usuario con su identidad y para esto surge el concepto de "Certificado Digital", que contiene la siguiente información:
•Identidad del usuario (Nombre, NIF, etc...).
•Clave Pública del usuario.
•Periodo de Validez del Certificado.
•Identidad de la Autoridad Certificadora (entidad que emite el certificado).
•Firma digital del certificado (los datos anteriores más otras posibles extensiones personalizables, p.e. la dirección de correo electrónico), generada por la Autoridad Certificadora.
Esta información se encapsula en un formato estándar, definido por la norma ISO X.509 versión 3. Generalmente existirá un repositorio (p.e. directorio LDAP) en el que se publican todos los certificados gestionados por la PKI y puede ser consultado por otros usuarios de la PKI que quieran enviar información cifrada o verificar firmas digitales.
Tipos de Certicados
Certificados Clase 1: Son emitidos unica/ a individuos, donde no se verifica la identidad, por lo tanto no permite autenticarla.
Certificados Clase 2: Son emitidos unicamente a individuos que confirman la informacion proporcionada por el suscriptor.Son datos fiables.
Certificados Clase 2 (no reconocidos):Usados para transaciones de bajo riesgo.
Certificados clase 2 (reconocidos): Pueden usarse como soporte de firmas electronicas legal/ reconocidas.
Certificados Clase 3: Son los que requieren evidencias probatorias de la identidad del sujeto o de una URL.
Bibliografia.
http://www.eurologic.es/soluciones/que-es-pki.htm
www.microsoft.com/.../images/04fig4-2_big.gif
Mauricio Ortiz Morales
Docente Admon de Redes de Computadores
Centro de Servicios SENA Medellin.
Una PKI bien construida debe tener una arquitectura proporcionar a:
• Autenticidad. La firma digital tendrá la misma validez que la manuscrita.
• Confidencialidad, de la información transmitida entre las partes.
• Integridad. Debe asegurarse la capacidad de detectar si un documento
firmado ha sido manipulado.
• No Repudio, de un documento firmado digitalmente.
Su arquitectura seria:
1. La infraestructura de llave publica o PKI
2. El modelo PKIX, o modelo de las entidades que gestionan la infraestructura de llave publica, degsinando funciones y protocolos.
3. Las politicas y praticas de certificacion CPS y CP.
La arquitectura PKI se encuentra: Internet Certificate and CRL Profile RFC 3280
> Especificada Internet Engineering Task Forge. http://ietf.org
El Modelo PKIX
En la imagen que veran a continuacion, el usuario va a acceder a una pagina de una entidad bancaria, con la cual requiere tener un canal de comunicacion seguro.Primero abre su browser o navegador y digita la direccion web del banco, la cual hace una serie de peticiones para enviar el certificado al usuario firmado por una autoridad de certificadora ya reconocida y dar tranquilidad sobre la autenticidad de la identidad del banco.
Contiene 5 componentes
1. Entidades Finales: Quien solicita la llave o se pretende identificar
2. Autoridad de Certificacion: La que emite los certificados y es la parte de la credibilidad de la llave publica. Firma los certificados con su llave privada, dando fe de que es en la verificacion de las llaves asignadas son a quien corresponde.
3. Autoridad de Registro: Realiza el proceso de registro de las entidades finales, validad los atributos, genera los secretos compartidos que permiten el proceso de inicializacion y certificacion.
4. Repositorios: Metodo que permite guardar la informacion de PKI "Certificados y CRL", viendo tambien el status de revocacion de los certificados.
5. Emisores CRLs "Certificate Revocation List Issuer":Son listas de certificados que han dejado de ser validos.
Contenido del Certificado.
Es necesario poder vincular la clave pública de un usuario con su identidad y para esto surge el concepto de "Certificado Digital", que contiene la siguiente información:
•Identidad del usuario (Nombre, NIF, etc...).
•Clave Pública del usuario.
•Periodo de Validez del Certificado.
•Identidad de la Autoridad Certificadora (entidad que emite el certificado).
•Firma digital del certificado (los datos anteriores más otras posibles extensiones personalizables, p.e. la dirección de correo electrónico), generada por la Autoridad Certificadora.
Esta información se encapsula en un formato estándar, definido por la norma ISO X.509 versión 3. Generalmente existirá un repositorio (p.e. directorio LDAP) en el que se publican todos los certificados gestionados por la PKI y puede ser consultado por otros usuarios de la PKI que quieran enviar información cifrada o verificar firmas digitales.
Tipos de Certicados
Certificados Clase 1: Son emitidos unica/ a individuos, donde no se verifica la identidad, por lo tanto no permite autenticarla.
Certificados Clase 2: Son emitidos unicamente a individuos que confirman la informacion proporcionada por el suscriptor.Son datos fiables.
Certificados Clase 2 (no reconocidos):Usados para transaciones de bajo riesgo.
Certificados clase 2 (reconocidos): Pueden usarse como soporte de firmas electronicas legal/ reconocidas.
Certificados Clase 3: Son los que requieren evidencias probatorias de la identidad del sujeto o de una URL.
Bibliografia.
http://www.eurologic.es/soluciones/que-es-pki.htm
www.microsoft.com/.../images/04fig4-2_big.gif
Mauricio Ortiz Morales
Docente Admon de Redes de Computadores
Centro de Servicios SENA Medellin.
martes, 27 de enero de 2009
Seguridad Informatica
Cuando hablamos de seguridad informatica, tenemos que hacernos unas preguntas basicas y primordiales;
QUE SE QUIERE PROTEGER?
QUE RIESGOS PUEDO SUFRIR?
DE QUE FORMA PUEDO PLANIFICAR O PREVENIR?
El crecimiento de la preocupacion por la seguridad y uso masivo de la internet, a llevado a popularizar la terminologia tecnica asociada a la criptografia.
De esta forma comienza a surgir un interrogante sobre, amenazas, riesgos,vulnerabilidad y ataque, dando paso a unos parametros importantes con los cuales resuelven estas dudas dentro de la organizacion.
los aspectos mas importantes serian la confidencialidad, integridad, disponibilidad y el no repudio.
NORMAS ISO
Organizacion Internacional de estandares. ISO
La Comision Electrotecnica Internacional. IEC
Para tener una publicacion de un estandar internacional del comite se requiere al menos la aprobacion del 75% de los organismos nacionales que emiten el voto; la cual
conforman ISO/IEC que es el comite tecnico evaluador.
ISO 17799
Antes de que empieze a surgir un estandar, primero se debe tener en cuenta por que la necesidad o la problematica a solucionar.
en el 17799, se encontraron los stes puntos a desaarrollar.
1. Diferentes criterios para evaluar.
2. multitud de estandares.
3. al reconocer el 7799 como estandar intanacional, como el mas extendido y aceptado.
ISO 17799 es una norma dirigida aquellos responsables de iniciar, mantener y asegurar la informacion de una organizacion.
Esta norma tambien define a la informacion como un activo que posee valor para mantener la integridad y ver reflejado esto en el retorno de la utilidad de las inversione y oportunidades de negocio.
Siendo tambien una norma no certificable, pero reconoce (SGSI) Sistema de Gestion de la Seguridad de la Informacion, de la norma UNE 71502 certificable.
En el esquema anterior tiene una pequeña introduccion a la historia o evolucion de la norma.
CONTROLES
1. Politica de seguridad: dirige y da soporte a la gestion de la seguridad de la informacion
2. Aspectos organizativos para la seguridad: gestiona la seguridad de la infomacion dentro de la organizacion; mantiene la seguridad de los recursos de tratamiento de la informacion y de los activos de informacion de la organizacion que son accedidos por terceros y mantiene la seguridad de la informacion cuando la responsabilidad de su tratamiento se ha extrenalizado a otra organizacion.
3. Clasificacion y control de activos: mantiene una proteccion adecuada sobre los activos de la organizacion y asegura un nivel de proteccion adecuado a los activos de la informacion.
4. Seguridad ligada al personal: reduce el riesgo de lo errores humanos, robos, fraudes o mal uso de la instalcion y los servicios; asegura que los usuarios son conscientes de las amenazas y riesgo en el ambito de la seguridad de la informacion, y que estan preparados para sostener las politicas de seguridad de la organizacion y minimiza los daños provocados por incidencias de seguridad y por el mal funcionamiento controlandolo y aprendiendo de ellos.
5. Seguridad fisica y del entorno: evita el acceso no autorizado, daños e interferencias contra los locales y la informacion de la organizacion; evita perdidas, daños o comprometer los activos asi como la interrupcion de las actividades de la organizacion y previene las exposiciones a riesgos y a robos de la informcion y de recursos de tratamiento de informacion.
6. Gestion de comunicacion y operaciones: asegura la operacion correcta y segura de los recursos de tratamiento de la informacion; minimiza el riesgo de fallos en el sistema; protege la integridad del software y de la informacion; mantine la integridad y la disponibilidad de los servicios de tratamiento de infomacion y de comunicacion; asegura la salvaguarda de la informacion en las redes y la proteccion de su infraestructura de apoyo; evita daño a los activo e interrupciones de actividades de la organizacion y previene la perdida, modificacion o mal uso de la informacion intercambiada entre organizaciones.
7. Control de acceso: controla los accesos a la informacion; evita acceso no autorizado a los sistemas de informacion; proteje los servicios en red; evita acceso no autorizado a ordenadores; evita el acceso no autorizado a la infomacin contenida en el sistema; detecta actividades no autorizadas y garantiza la seguridad de la informacion cuando se usan dispositivos de informacion movil o teletrabajo.
8. Desarrollo y mantenimiento de sistema: asegura que la seguridad esta incluida dentro de los sistemas de informcion; evita perdidas, modificaiones o mal uso de los datos de usuario en las aplicaciones; protege la confidencialida, integridad y autenticidad de la informacion; asegura que los proyectos de Tecnologias de la Informacion y las actividades complementarias son llevadas a cabo de una forma segura y mantiene la seguridad del software y la informacion de la aplicacion del sistema.
9. Gestion de continuidad del negocio: reacciona a la interrupcion de actividades del negocio y protege sus procesos critiicos frente a grandes fallos o desastres.
10. Conformidad con la legislacion: evita el incumplimiento de cualquier ley, estatuto, regulacion u obligacion contractual y de cualquier requerimiento de seguridad; garantiza la alineacion de los sistemas con la politica de seguridad de la organizacion y con la normativa derivada de la misma y maximiza la efectividad y minimiza la interferencia de o desde el proceso de auditoria del sistema.
Suscribirse a:
Entradas (Atom)
