OpenVPN con easy-rsa

Recientemente he tenido que acceder desde dispositivos móviles a cámaras de vigilancia instaladas dentro de una red interna; para lo que utilicé OpenVPN, y armé un pequeño tutorial de cómo hacerlo fácilmente configurando la Autoridad de Certificación con easy-rsa que ya viene disponible en el mismo paquete de OpenVPN.

OpenVPN

En resúmen, se configura un equpo dentro de la red como servidor OpenVPN que recibe las conexiones entrantes al puerto 1194/UDP y reenvía el tráfico que llega por la VPN hacia la red interna, enmascarando con su propia IP.

El tutorial está disponible en este enlace al wiki.

Cualquier sugerencia de mejora o críticas, espero comentarios en este artículo.

OpenShift

openshift

A partir del 8 de diciembre de 2014, este blog está alojado en OpenShift, el PaaS de RedHat y quiero compartir mi experiencia de uso y configuración de un PaaS.

Un PaaS es servico al cual se le entrega la aplicación y más o menos auto-mágicamente la aplicación queda presentada en Internet.  En el caso de este blog la aplicación es WordPress por lo que me limité a subir el código  (de mi template, idioma, etc.) y mis datos (archivos) y aquí lo estás viendo.  Por otro lado, el PaaS permite despreocuparse de la infraestructura y la plataforma, es decir, que no debo pensar en la versión del sistema operativo ni su actualización, su configuración, las políticas de seguridad, la red, los usuarios, en fin, nada que no sea estrictamente mi aplicación.

Obviamente, un servicio PaaS es más caro que un servicio de infraestructura de cloud computing (IaaS), el cual a su vez es más caro que un simple VPS fuera de una arquitectura de cloud computing, solamente por el hecho de que hay servicios que alguien está prestando y sobre los que tu no debes preocuparte.

Pero volviendo a OpenShift debo decir que mi primer impresión ha sido muy positiva y creo que hay cosas que diferencian a esta oferta de PaaS sobre otras.

OpenShift ofrece «contenedores» que llama gears y que en la cuenta gratis se pueden tener hasta 3 de los más chicos.  Los gears poseen quota de recursos por cgroups y están orientados a alojar una aplicación cada uno.  Si bien se podría alojar más de una aplicación, solo un dominio internet puede referenciar a cada gear y creo que no vale la pena el esfuerzo intelectual e alojar muchas aplicaciones en uno solo y luego mantenerlas.

Adicionalmente, Openshift ofrece servicios que pueden ser incoprorados a un gear y que llama cartridges. De esta forma se puede levantar un gear con PHP y luego agregarle MySQL, luego CRON, luego POSTFIX, etc., según la aplicación vaya requiriendo.

Aquí dejo un esquema de la arquitectura de openshift completa:

openshiftcompletepicture

aunque sugiero ir a un sitio interactivo que explica cómo OpenShift funciona de una forma muy dinámica y comprensible.

Openshift ofrece aplicaciones pre-instaladas con las cuales iniciar un gear, como WordPress, Cacti, Redmine, Drupal, OwnCloud, Tomcat, Node.JS, etc., o simplemente lenguajes para luego montar nuestra propia aplicación; Ruby, Python, Java, PHP.

Captura de pantalla 2014-12-09 a las 3.28.29 PM

Una vez arrancado el gear con la aplicación pre-instalada se clona un repositorio git y luego se modifica la aplicación localmente, para hacer un ‘git push’ con los cambios, que quedan activados inmediatamente.

Para administrar openshift, además de la interfaz web, existe una herramienta de línea de comando muy simple de instalar con ruby. Pero lo que realmente me enamoró de OpenShift es la posibilidad de poder hacer ssh al gear y tener línea de comandos; poder subir mis datos (yo hice una migración) mediante scp o rsync, lo que acerca OpenShfital nivel que conozco (de IaaS) y en el cual me siento cómodo.

No he utilizado otros PaaS, pero a mi me ha resultado simple poner mi blog y mi wiki a correr en OpenShift; con una pequeña curva de aprendizaje para conocer su filosofía de trabajo para el mantenimiento de mi aplicación y mis datos, ya ven todo online.

 

Cómo procesar la bibliografía en LaTeX

Muchas veces es algo confuso cómo procesar el archivo de bibliografía con LaTeX, pues al tratarse de referencias cruzadas entre el texto y la página de referencias bibliográficas, necesita de un proceso algo particular.

1. Crear un archivo .bib. Este es la base de datos para guardar todas las referencias bibliográficas. Generalmente se puede reutilizar un archivo .bib anterior que se tenga hecho y modificarle los datos. Este archivo debe contener todos los tipos de citas: artículo de revista o publicación periódica, libros, publicaciones, comunicaciones personales, página web, audiovisuales, etc.

2. Colocar las entradas en el archivo .bib. Una entrada tiene tres partes principales: tipo de referencia para que LaTeX pueda conocer el estilo; la etiqueta con la que se referencia desde el cuerpo de texto con cite{ } y los datos. Con kile las entradas en el archivo .bib pueden ser insertadas de forma fácil, seleccionando el tipo de referencia del menú:

kile bibtex

3. Agregar una entrada bibliography{nombre-del-archivo-bib-sin-extension} al final del archivo latex (.tex) y justo antes del final, o sea previo a end{document}

4. Cuando quiera citar algo en el cuerpo del mensaje, se hace agregando cite{etiqueta}.

5. Para compilar la bibliografía ejecutar:
– latex documento.tex
– bibtex documento
– latex documento.tex
– latex documento.tex
Ambos comandos latex y el comando bibtex es una buena forma de evitar que algo quede sin definir o apuntar dentro del documento. Kile ya realiza esta tarea de forma efectiva, simplemente seleccionando el botón de QuickBuild:

Kile quickbuild

También es posible usar un guión (makefile) para crear sus documentos, para los que les guste la línea de comando y editar sus archivos latex con vim o emacs.

Servicio de identificación en OpenStack

El servicio de identificación (keystone) de OpenStack realiza las siguientes funciones:

  • Controla los usuarios y sus permisos.
  • Expone el catálogo de los servicios disponibles para ser consumidos mediante API.

Cada servicio instalado se debe registrar en Keystone, de esta forma se estará controlando el acceso a cada uno y cómo está disponible en la red.

Para comprender el servicio de identificación, es necesario entender estos conceptos:

User / usuario
Representación de una persona, sistema o servicio que utiliza OpenStack. El servicio de identificación permite validar los pedidos que son hechos por el usuario.  Los usuarios pueden ingresar y obtener tokens para acceder a recursos.  Los usuarios son asignados a un proyecto en particular y quedan contenidos dentro del proyecto.
Credentials / credenciales
Datos que confirman la identidad de un usuario. Por ejemplo: nombre de usuario y clave,  nombre de usuario y llave API, o token obtenido del sistema de identificación.
Authentication / autenticación
El proceso de confirmar la identidad de un usuario. El servicio de identificación confirma un pedido validando un conjunto de credenciales que envía el usuario.

Estas credenciales son inicialmente el nombre y la clave, o el nombre de usuario y una llave de API. Cuando el usuario se valida, el sistema de identidad emite un token de autenticación que el usuario puede usar para pedidos futuros.

Token / pase
Es una cadena de texto alfanumérica utilizada para acceder a la API y recursos de OpenStack. Este pase puede ser revocado en cualquier momento y es valido por un período determinado.

Actualmente el sistema de identificación de OpeneStack soporta autenticación mediante token aunque la intention es soportar protocolos adicionales en el futuro. El objetivo principal es ser un servicio de integración y no se aspira a dar una solución integral de administración de identificación.

Tenant / beneficiario

Es un contenedor para agrupar o aislar recursos. Dependiendo del servicio, un tenant puede ser un cliente, una cuenta, una organización o un proyecto.
Service / servicio
Un servicio de OpenStack, como ser de cómputo (nova), para guardar objetos (swift), de imágenes (glance). El servicio presenta uno o más endpoints mediante los cuales los usuarios pueden acceder a los recursos y realizar operaciones.
Endpoint / llegada

Es una dirección de red accesible para acceder a un servicio, usualmente una URL. Si se utiliza una extensión de perfiles (templates), un perfil de endpoint puede ser creado, el cual representa todos los servicios que pueden ser consumidos y que están disponibles entre las regiones.

Una personalidad con un conjunto definido de permisos de usuario y privilegios para realizar operaciones específicas.

En el servicio de identificación, un token que es emitido a un usuario que incluye una lista de roles. Los servicios que están siendo invocados por un usuario determinan cómo serán interpretados los conjuntos de roles que dicho usuario tiene y a cuáles operaciones o recursos se tendrá acceso.

Keystone Client / cliente de keystone
Una interfaz de línea de comando para el API keystone de identificación de OpenStack. Por ejemplo, los usuarios podrán ejecutar keystone service-create y keystone endpoint-create para registrar servicios en sus instalaciones de OpenStack.

El siguiente diagrama muestra el proceso de identificación de OpenStack:

Keystone

Este texto es la tradicción directa del manual de OpenStack con algunos agregados y modificaciones básicas que entiendo mejoran la comprension.

Administración de llaves SSH para aplicaciones

Las llaves de SSH permiten, por defecto validar la conexión al destino y cifrar el tráfico entre el cliente y el servidor. Con algo de configuración es posible validar el orígen contra el servidor y de esa forma en lugar de conocer la clave para acceder, la validación es por certificados. Cuando empezamos a utilizar aplicaciones y a automatizar los accesos aparecen los compromisos de seguridad, esta presentación aborda las configuraciones básicas para la administración de las llaves SSH cuando se usan para otorgar accesos a las aplicaciones.

Público objetivo: Casi cualquiera que utilice SSH para vincularse con servidores, equipos y aplicaciones remotas.

Requisitos: Conocimientos de SSH o haberlo utilizado como cliente.

Presentación realizada en:

  • 15 nov 2014 – Techmeetup 2014 – (Meetup Space) – Torre de las Comunicaciones, Montevideo, Uruguay

Receta de Tunel para llegar a tu computador

A casi todos que trabajamos en tecnologías de la información nos ha pasado tener alguna vez la necesidad de que, ya sea un compañero, un gerente, un cliente, o alguien más, acceda a nuestra computadora y nos hemos encontrado con problemas de todo tipo, desde que estamos detrás de un firewall en una red privada, nuestra aplicación está en una máquina virtual, nuestro tráfico es solo saliente mediante proxy, etc. etc.

Muchos utilizan algunas herramientas que permiten dar algun acceso, aunque más no sea a compartir la pantalla, tal vez por Google Hangout, mediante Skype, ScreenHero, Team Viewer o con soluciones más optimas como NGrok.

Esta presentación, en formato ligthning talk de 5 minutos, es una receta para construir un tunel, solamente disponiendo de cualquier máquina accesible con Linux, utilizando SSH, y permitiendo abrir un canal que al conectarse a él se accede hasta nuestra máquina o aplicación local.

Público objetivo: Está pensado para cualquier persona que tenga problemas con compartir una aplicación con personas remotas.

Requisitos: Ganas de divertirse

Ligthning talk presentada en:

  • 15 nov 2014 – Techmeetup 2014 – Torre de las Comunicaciones, Montevideo, Uruguay

PAM Pluggable Authentication Modules

El sistema de módulos encastrados para autenticación (Pluggable Authentication Modules (PAM)) es el método por el cual los sistemas Linux implementan mecanismos de autenticación y permiten que las aplicaciones no tengan necesidad de armar mecanismos propios, sino que invocan a PAM para tal fin.

La autenticación en PAM se basa en bibliotecas dinámicas llamadas módulos PAM que se vinculan o encastran unos con otros, formando una «pila» que completa el proceso de validación que requiere la aplicación.

Esta pila se arma tomando en cuenta cuatro procesos se combinan para armar la autenticación y que pueden variar según la aplicación, el entorno, las necesidades de seguridad, los dispositivos disponibles, el tipo de usuario, etc, y son:

Métodos de autenticación y base usuario/clave como ser password, PIN, scanner biométricos, sensores, lectores de tarjeta; y conexiones con bases SQL, LDAP, Active Directory, Kerberos, etc.

Manejo de password  los sistemas de cifrado, los métodos de validación o resolución de password y todo lo vinculado a la administración de la password, como ser su vigencia, advertencia, control de diccionario, histórico de cambios, etc.

Gestión de cuenta que verifica si la cuenta está activa, si el usuario tiene permisos para la validación, si está dentro de los parámetros de horario de acceso, si ha pago la mensualidad, y cualquier otra comprobación de cuenta que sea necesaria.

Definición y configuración de la sesión que tendrá el usuario de acuerdo a lo que define su cuenta o entorno que van desde configuración de variables de ambiente, hasta notificación a sistemas de billing o accounting.

No debemos olvidar que mediante PAM se gestiona la validación del común login, pero también puede ser utilizado para acceso a una puerta de una caja fuerte o controlar el pasaje en una barrera de peaje carretero.

PAM

Configuración de PAM

PAM se configura en el directorio /etc/pam.d y allí se encuentra un archivo por cada aplicación. En versiones antiguas se utilizaba el archivo /etc/pam.conf que aún es manejado por PAM por compatibilidad, pero que ya no aparece en sistemas modernos.

Archivos de configuración de PAM

En /etc/pam.d se encuentran archivos que corresponden con el nombre de la aplicación, por ejemplo sshd y cada línea de este archivo es un módulo de PAM que se configura así:

 tipo_de_módulo   control_entre_módulos   archivo_módulo   argumentos_módulo

Dependiendo de cómo esté configurado PAM, también existen algunos archivos que son comunes a otros y que se vinculan mediante directivas include:

 @include common-auth

Tipo de módulos PAM

PAM utiliza cuatro tipos o grupos de módulos:

  • auth
  • password
  • account
  • session

y coinciden con las funciones principales de PAM que se describen previamente.

El tipo de módulo PAM es el rol que el módulo (biblioteca dinámica) tendrá en el proceso de validación (pila) y un mismo módulo puede, perfectamente, cumplir más de un rol.

Los módulos son colocados unos detrás de otros armando la «pila» de validación, por lo cual el orden en que un módulo precede a otro es muy importante y permite que se puedan armar las combinaciones necesarias para el éxito o fracaso de la validación.

Es posible editar un archivo de pila y agregar nuevos módulos en cualquier momento, por ejemplo si se quiere validar mediante Google Authenticator

Control entre módulos PAM

Cada módulo cuando es revisado genera un resultado de éxito o fracaso.  Los controles permiten que PAM pueda saber qué hacer con el resultado.  Cómo los módulos serán evaluados en orden, el control habilita a asignarle importancia a un módulo respecto al siguiente.

Las opciones de control son, en principio, cuatro:

  • módulos required deben retornar éxito para que se permita autenticar. Si el módulo required falla, el usuario no será notificado hasta que los otros módulos del mismo tipo sean revisados,
  • módulos requisite deben retornar éxito para que ser permita autenticar. Si el modulo requisite falla, el usuario es notificado inmediatamente del fallo de autenticación con un mensaje,
  • módulos sufficient serán ignorados si fallan. Pero si un suficiente devuelve éxito y no se tiene pendiente ningún módulo required con falla, ningun otro módulo de este tipo es verificado y se considerará éxito en la autenticación global,
  • módulos optional no son cruciales para el éxito o fracaso de la autenticación global. Juegan un rol cuando ningún otro módulo ha tenido éxito o fracaso; en ese caso los módulos optional determinan el resultado de la autenticación.

Se puede resumir que los módulos required no son críticos, mientras que los sufficient y requisite tienen efecto inmediato.

Existe además un sistema de control extendido que permite una configuración más fina del la interacción entre los módulos. Cuando se utilizan estos controles extendidos las variables de control están encerradas entre paréntesis rectos, por ejemplo:

 session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close

Archivos de módulos PAM

Los archivos de módulos PAM son, como se dijo, bibliotecas dinámicas (.so) que se encuentran en el directorio /lib/security (RedHat) o en /lib/x86_64-linux-gnu/security (Debian), aunque también se pueden incluir con el path completo en forma explícita.

Argumentos de módulos

PAM utiliza argumentos para pasar información a los módulos durante su ejecución, lo que permite otorgar mayor flexibilidad al sistema PAM.

Por ejemplo, es posible hacer que el módulo de validación de clave estándar de Linux requiera claves de un mínimo de 8 caracteres, evite cambiar la clave por cosas obvias (cambio mayúsculas minúsculas, rotación simple de caracteres, palíndromos) y utiliza algoritmo sha512 para el cifrado de la misma.

 password [success=2 default=ignore] pam_unix.so obscure sha512 min=8

Documentos sobre PAM

Parte de este artículo está basada en los siguientes documentos:

También recomiendo las páginas de manual de cada módulo, como ser man pam_unix que tiene toda la información del módulo, incluyendo sus argumentos.

GNUpg – Refrescar llavero con Enigmail

La tarea de refrescar el llavero de claves públicas permite mantener al día la información de las llaves públicas que se utilizan para cifrado y verificación de mensajes firmados.

Si alquien desea hacerlo por línea de comandos es solamente escribir:

$ gpg --refresh-keys