Archives julio 2014

Fortificando la autenticación de usuarios en WordPress

Al margen de la elección de contraseña, es una opinión, y cada vez más generalizada, que para aumentar la seguridad en la autenticación de los usuarios, debemos recurrir a sistemas MFA (Multi-Factor Authentication). Estos sistemas consisten en incluir diferentes factores de autenticación (2 o más): uno basado en algo que conocemos (por ejemplo, el clásico de la contraseña); otro en algo que poseemos (el móvil, por ejemplo) y/o algo que solo es el usuario (por ejemplo, su huella o cualquier característica biométrica).

Si queremos mejorar la seguridad de nuestro blog, existen pluggins que implementan un mecanismo 2FA (doble factor de autenticación) basado en Google Authenticator. En este blog estoy probando: WP Google Authenticator.

Es muy fácil de utilizar:

  1. Lo instalamos (Plugins>Añadir Nuevo y tras esto: Activar)
  2. Tras este proceso, en Ajustes, tendremos las opciones del plugin. En mi caso activé que el número máximo de veces que se puede autenticar un usuarios sin 2FA sea de 3)
  3. En Usuarios>Tu Perfil, abajo aparece información importante. Por un lado, el botón Get QR Code al que pulsaremos para obtener el código QR  sincronizará la aplicación Google Authenticator de nuestro móvil con el plugin. Para esto:
    • Arranqueremos en nuestro móvil Google Authenticator,
    • En Menú: Configurar Nueva cuenta,
    • Escanear código ¡et voila!
  4. Además en Usuario>Tu perfil tendremos el código de recuperación y tu clave secreta que no debes compartir con nadie.

Ahora, cada vez que queremos acceder al control de nuestro WordPress, nos encontraremos con:

Captura de pantalla de 2014-07-30 12:57:32

Quien disponga de un hosting propio al que se conecte con sesiones de trabajo que quiere fortalecer, también podemos utilizar Google Authenticator para implementar  un 2FA en el servicio SSH. Esto, en otra entrada que publicaré en breve 😉


Auditando tu blog de wordpress

Como buen gestor de contenidos existoso, WordPress está en el punto de mira de «muchas personas malas». Es por ello que, en mi opinión, debemos procurar disponer de un blog mínimamente seguro y una de las tareas que cualquiera puede hacer fácilmente es ejecutar una de las herramientas de análisis automático que existen. Una de estas herramientas, útil para comprobar las debilidades de nuestro blog basado en WordPress (como este que estás leyendo), es wpscan que nos permite localizar las versiones de los gestores de contenido, posibles archivos de elementos o temas sensibles y versiones de los plugins instalados.

Los pasos para su instalación en un sistema Debian son:

apt-get install git libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev ruby-dev ruby1.9.3
git clone https://github.com/wpscanteam/wpscan.git
cd wpscan
sudo gem install bundler && bundle install --without test development

Tiene múltiples opciones que podemos consular en la ayuda de la aplicación o en su sitio web (referencia 1). En esta entrada nos vamos a centrar solo en la ejecucuón de determinadas comprobaciones básicas:

  • Para enumerar los plugins que pudiéramos tener vulnerables:
ruby wpscan.rb -u www.mundoerrante.net --enumerate vp
  • Si queremos ver temas problemáticos:

ruby wpscan.rb --url mundoerrante.net --enumerate vt

  • Si queremos listar los usuarios del blog:

ruby wpscan.rb --url mundoerrante.net --enumerate u

Disclamer: Todas estas pruebas están hechas contra mi blog desde un punto de vista educacional y no deberían ser usadas para cualquier otro tipo de acción

Referencias:

  1. wpscan.org

Virtualhost con nombre en Apache y Nagios

RECORDATORIO: Si estás comprobando el funcionamiento de tu sitio web con Nagios y dispones de varios sitios definidos con VirtualHost basados en el nombre debes asegurarte que en la petición se mande el nombre del sitio deseado.

Si lo hiciéramos «a mano», la conversación desde el cliente nagios al servidor Apache sería así:

telnet nombre_servidor 80
GET / HTTP/1.0
HOST:nombre_servidor
línea en blanco
línea en blanco

Para comprobar la disponibilidad, Nagios utiliza la orden check_http internamente y, para asegurarnos que indica el nombre del servidor, la invocación debe incluir el parámetro «-u <nombre_servidor>»:

check_http -I -p 80 -u <nombre_servidor> -R "string a buscar"

Super User DO

SuDO es una herramienta que, como comentamos en esta entrada anterior, nos permite realizar una buena gestión de privilegios e implementar una administración compartida de los sistemas. En general, lo que nos permite es ejecutar las órdenes deseadas con los identificadores de usuario (UID y EUID) y grupo (GID y EGID) necesarios para su correcta ejecución, no es necesario que sea solo para  root. En el caso (bastante deseable) de que se necesite autenticar al usuario, esta acción se realizará con la contraseña del usuario que ejecuta la orden y no con la del usuario objetivo (es decir, NO con la de root).

La instalación es sencilla (sistemas Debian):

apt-get install sudo

Para la configuración: /etc/sudoers

Este es un fichero de texto en el que, cada línea, debe seguir la siguiente sintaxis:

[usuario/%grupo] [equipo] = [(id:gid del usuario objetivo)] órdenes

También admite alias con esta sintaxis:

alias nombre = elemento_alias

Los alias pueden ser de órdenes: Cmnd_Alias para lista de órdenes; User_alias para listas de usuarios; Host_alias, para listas de equipos

Un ejemplo de /etc/sudoers que usamos en la EPS es:

Cmnd_Alias CMDADMIN = /sbin/shutdown, /etc/init.d/sshd, /etc/init.d/network, /etc/init.d/rsysklog, /etc/init.d/nscd, /etc/init.d/tomcat, /etc/init.d/httpd, /etc/init.d/apache2
User_Alias USRWWWDATA = www-data, wwwadm
USRWWWDATA ALL= NOPASSWD: CMDWWWDATA

En este ejemplo se han definido 2 alias: CMDADMIN con la lista de comandos que van a poder ejecutar los usuarios listados en USRWWWDATA.

La última línea habilita la ejecución de las órdenes listadas en CMDWWWDATA por los usuarios definidos en USRWWWDATA como si las estuviera ejecutando el usuario root (no pone usuario objetivo por lo que es root). La expresión «como si las estuviera ejecutando» es una forma de expresarme. Como he comentado antes, la ejecución es con UID, EUID, GID y EGID de root (para este caso, en otros, con el del usuario objetivo.

De esta forma, los usuarios wwwadm y www-data pueden parar, reiniciar, lanzar Apache, Tomcat, nscd, ssh,… sin necesidad de conocer la contraseña del administrador.

También podríamos usar la directiva Defaults con la que podríamos definir determinadas opciones globales de comportamiento de sudo. Un uso interesante es:

Defaults env_reset, timestamp_timeout=1,passwd_timeout=2,passwd_tries=1

que implica que los usuarios tendrán:

  • Un solo intento de autenticación (passwd_tries=1),
  • tiempo de sesión sin solicitar de nuevo la contraseña de 1 minuto (timestamp_timeout=1),
  • timeout de 2 minutos.

Con la opción env_reset lo que se pretende es eliminar todas las variables de entorno del usuario salvo LOGNAME, SHELL, USER, USERNAME, MAIL y las de SUDO_*

Referencias:

  1. man 8 sudo
  2. man 5 sudoers
  3. Hardening de servidores GNNU/Linux, Carlos Álvarez Martín y Palo González Pérez, 0xWord, 2013

Administración de sistemas compartida

En mis clases de Administración de sistemas operativos en Red me gustaba recalcar, dentro del tema de gestión de usuarios, la importancia del usuario administrador (root) y cómo llegar a serlo. Su importancia radica, como sabemos, en que es el encargado de la ejecución de las tareas de administración, instalación, configuración, monitorización y seguridad de los sistemas de tal forma que, en infraestructuras de cierto tamaño, es fácil que existan varios administradores.

En estas circunstancias ¿cómo se reparten el trabajo? ¿por equipos/servidores? Y si el responsable de un servidor no está, ¿el resto se desentiende?  Para responder a esta última pregunta como un equipo profesional, debemos permitir la administración compartida y colaborativa  entre varios administradores y que puedan, cualquiera de ellos, administrar (ejecutar tareas de un administrador) un mismo sistema.

Una manera es conociendo todos la contraseña de root. En mi opinión no es una buena opción ya que diluye la responsabilidad. En GNU/Linux existe una utilidad que nos permite, precisamente, obtener las bondades mencionadas anteriormente sin necesidad de que todos los administradores conozcan la contraseña de root: sudo.

El uso de sudo tiene las siguientes ventajas:

  • Alta contabilidad: se registra las órdenes y quién las ejecutó en los registros de eventos del sistema (los logs)
  • Como ya he comentado: se limita el conocimiento del passwd de root a una única persona y sin limitar la labor de los operadores, por ejemplo, a los que les podemos dar autorizaciones concretas.
  • No se necesitan establecer sesiones de trabajo de root.
  • Los privilegios pueden ser revocados cuando se necesite.
  • Tenemos una lista de todos los usuarios con privilegios de root y qué es lo que pueden hacer con esta responsabilidad (está en la configuración del comando).
  • Las restricciones de acceso son dependientes del host, un fichero simple puede ser usado para el control de acceso a una entidad de red.

Como no es oro todo lo que reluce, también tenemos varias desventajas:

  • Una brecha en la seguridad de la cuenta de usuarios es equivalente a una brecha en la de root (para las acciones autorizadas)
  • Una mala configuración, como es el uso de path relativos para describir las órdenes autorizadas, puede provocar problemas debido a engaños con ejecuciones del «programas no controlados» como si fuera un programa permitido. Se arregla con el uso sin path absolutos en las configuraciones.

Para utilizarlo, debemos instalarlo y configurar el fichero /etc/sudoers, pero esto, será otro día…

 


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.