Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

miércoles, 30 de marzo de 2016

Cómo crear un segundo factor de autenticación en ssh

Tras una semana santa de desconexión tecnológica total, hoy vuelvo con algo muy curioso que estoy seguro que os resultará útil. Más de una vez he comentado que las contraseñas "planas" están destinadas a desaparecer o evolucionar, ya que han demostrado ser altamente inseguras... La mejor opción (en mi opinión) es recurrir a métodos de autenticación basados en claves pública y privadas, como se hace muy a menudo para accesos seguros SSH, pero esa solución es muy técnica y no es cómoda para todos los usuarios, con lo que hoy vengo a hablaros de una alternativa muy popular que es usada también en otras plataformas, tales como el acceso a la cuenta de Google: Se trata de la autenticación en dos pasos, también conocida como segundo factor de autenticación.

Portada_authenticator

La autenticación en dos pasos, no es ni más ni menos que un recurso que tras introducir la clave del usuario, obliga a éste a introducir una segunda clave; clave que únicamente posee un dispositivo móvil y que es completamente aleatoria. Además dicha clave "extra" cambia tras pasar unos segundos, con lo que a menos que se posea el móvil en cuestión y se tenga la clave "habitual" del usuario, es muy complicado tener acceso a la cuenta protegida mediante dicho método. Imaginemos que alguien ha obtenido la contraseña de nuestro usuario... Éste no podría acceder a nuestra cuenta gracias a esta medida extra de seguridad, ya que solamente el dueño del móvil tendría la segunda clave en su poder, lo que hace que esta medida de seguridad sea muy interesante. Aunque hoy centraremos dicha funcionalidad en las conexiones ssh, podemos ver en la actualidad múltiples aplicaciones y/o servicios que contienen dicha medida de seguridad, con lo que en caso de tener la posibilidad de activar el segundo factor de autenticación en alguna cuenta y/o servicio web es muy recomendable hacerlo.

Para lograr el segundo factor de autenticación en conexiones SSH necesitaremos instalar Google Authenticator tanto en nuestro móvil como en el equipo que queremos salvaguardar. Para el primero con tan solo descargarlo del Play Store sería suficiente, pues es una aplicación gratuita que no tiene complicación alguna para instalarla... En cuanto a la instalación del la herramienta en el servidor, al ser una utilidad "poco habitual", no se encuentra dentro de los repositorios oficiales... Pero no pasa nada, ya que podemos obtenerla gracias al conocido git; si bien antes son necesarios instalar algunos paquetes; paquetes que en este caso sí que estarían incluidos en los repositorios. Estos paquetes serían ntp, make, gcc y libpam0g-dev:

apt-get install git ntp make gcc libpam0g-dev

Además de forma opcional podemos instalar qrencode, cosa que (en mi opinión) es bastante recomendable:

apt-get install qrencode

Con los requisitos cumplidos, ahora podemos obtener los paquetes relacionados con Google Authenticator; la URL en la que están alojados los paquetes sería https://github.com/google/google-authenticator, así que la operación para descargar e instalar esta utilidad sería la siguiente:

  1. mkdir /usr/src/2FA
  2. cd /usr/src/2FA
  3. git clone https://github.com/google/google-authenticator
  4. cd google-authenticator/libpam
  5. make && make install

Con esto la librería que trabaja con Google Authenticator estaría disponible, pero no activada... La librería está relacionada con los módulos PAM (Pluggable Authentication Modules); en concreto con el módulo PAM de ssh, el cual es /etc/pam.d/sshd. Hablar sobre PAM requeriría un post entero, ya que es algo muy completo y complejo, pero se podría decir a groso modo que el módulo PAM, sshd, se encargaría de gestionar las tareas de autenticación relacionadas con las conexiones ssh. En dicho módulo tenemos dos posibilidades:

  • Hacer que sea 100% necesario interactuar con el módulo de google en TODAS las conexiones ssh. Esto lo lograríamos ejecutando este comando:
echo 'auth required pam_google_authenticator.so' >> /etc/pam.d/sshd
  • Hacer que se ejecute el segundo factor de autenticación únicamente en las cuentas preparadas para ello; es decir en cuentas que soporten dicha funcionalidad debido a que se ha creado una clave secreta que se usa para sincronizarse con el móvil. Generalmente es más recomendable esta opción ya que esto no nos obligaría a crear claves en todas las cuentas con acceso por ssh, sino que solamente aquellas que nosotros queramos.

echo 'auth sufficient pam_google_authenticator.so' >> /etc/pam.d/sshd

Por motivos de compatiblidad con la modificación realizada en este módulo, es necesario también modificar el comportamiento del servicio ssh; en concreto sería necesario modificar el parámetro ChallengeResponseAuthentication. Este parámetro se encontraría dentro del fichero /etc/ssh/sshd_config y su valor por defecto sería "no"; aunque generalmente dicho valor no da problemas, en este caso habría que cambiar su valor a "yes" para que el módulo de google funcione correctamente, con lo que el valor quedaría tal que así:

ChallengeResponseAuthentication yes

Obviamente, para aplicar los cambios realizados en la configuración del servicio ssh habría que reiniciarlo:

/etc/init.d/ssh restart

Ahora únicamente habría que configurar las cuentas en las que queramos aplicar el segundo factor de autenticación; la sintaxis para hacerlo sería:

su - usuario -c /usr/local/bin/googe-authenticator

Por ejemplo para el usuario ivan sería:

su - ivan -c /usr/local/bin/googe-authenticator

Tras responder sí a todas las preguntas que nos vaya lanzando el comando habremos generado lo siguiente:

  • Una URL en la que podremos visualizar un código QR legible desde el móvil.
  • El mismo código QR en la consola en caso de haber instalado qrencode.
  • La clave que tendremos que introducir en el Google authenticator del móvil en caso de no tener lector de códigos QR.
  • El código de verificación que irá cambiando cada poco segundos.
  • Una lista de claves de emergencia que se pueden usar en caso de haber perdido el móvil.

Supongamos que tenemos la capacidad de leer el código QR, ya sea con la URL o mediante el QR mostrado en la terminal; solo habría que coger el móvil y abrir Google Authenticator; después tan solo habría que seleccionar la opción Seleccionar código de barras y leer el código QR.

ga1
Pantalla principal Google Authenticator sin configurar

ga2

Configuración de nueva cuenta


Una vez sincronizados el smartphone y el equipo, veremos un código que cambia cada 30 segundos junto con el nombre del equipo con el que nos hemos sincronizado. Ahora si nos logueamos al equipo en cuestión por ssh, veremos que tras introducir la contraseña, nos pedirá un código de verificación; dicho código sería el mostrado en el smartphone:

codigo_verificacion


Con esto ya tendríamos un entorno con un segundo factor de autenticación perfectamente funcional.

Espero que os haya resultado útil.

Saludos.

martes, 22 de marzo de 2016

Cómo conectarte a una red wifi desde la terminal en Linux

Hoy os vengo con un uso ligeramente distinto al habitual de las redes inalámbricas; generalmente cuando queremos conectarnos a una red wifi lo hacemos mediante una interfaz gráfica y la ayuda de recursos tales como Network Manager, pero a veces carecemos de dicha interfaz; ya sea porque el equipo tiene muy pocos recursos o porque directamente no se quieren añadir funcionalidades innecesarias al equipo, ya que generalmente se usará más como servidor que como equipo orientado al usuario final. Es por eso que en ocasiones como ésta, es necesario buscar alternativas al entorno gráfico, alternativas que pueden ser desde muy sencillas y orientadas a conectarse siempre a la misma red inalámbrica a recursos un poco más laboriosos pero que están orientados a adaptarse a todo tipo de redes. En el articulo de hoy veremos ambas opciones, pudiendo seleccionar cualquiera de ellas dependiendo de nuestras necesidades.

wifiterminal

Método "laborioso" pero flexible

Comencemos con el método de conexión más versátil de todos, aquel que generalmente más usaremos y que nos permitirá conectaros a cualquier Wifi a la que tengamos acceso (de forma normal, es decir sin "forzar" ninguna contraseña ni recurrir a métodos ilícitos) con la misma flexibilidad que nos ofrecería Network Manager. Para ello se combinan tres herramientas que está instaladas por defecto en el sistema: ifconfig, dhclient, iwlist y iwconfig; las dos últimas solamente podrían usarse en caso de tener instalada alguna tarjeta de red inalámbrica, pero en nuestro caso esto se daría por hecho pues en caso contrario el post carecería de sentido.

Lo primero que tendríamos que hacer sería habilitar nuestra interfaz inalámbrica, la cual probablemente se encuentre por defecto inhabilitada. Esto es tan sencillo como hacer:

ifconfig wlan0 up

En caso de no funcionaros el comando habría que revisar si poseemos los drivers adecuados instalados; una buena forma de comprobar si nuestro sistema detecta adecuadamente nuestros elementos de red; ya sean ethernet o Wifi, sería consultando el fichero /etc/udev/rules.d/70-persistent-net.rules; en caso de aparecer NAME="wlan0", el sistema estaría detectando correctamente la interfaz de red. Con la interfaz de red activa, tendríamos que analizar qué redes tenemos cerca de nuestro equipo, comprobando su ESSID, el cifrado usado, la calidad de la señal, etc... El comando para realizar dicho análisis sería:

iwlist wlan0 scan

El ESSID sería el nombre al que haríamos referencia cuando queremos conectarnos a una red inalámbrica; nombre que dependiendo de si el router ha sido configurado o no, puede tener un nombre intuitivo, o puede tener un nombre como WLAN_... He de suponer que nos conectaremos a una red con una contraseña cifrada (hacer lo contrario sería una imprudencia), con lo que emularemos una conexión a una red en la que es necesario introducir la contraseña.

Supongamos que hemos detectado una red con el ESSID PRIVADO y con la contraseña N03ntr3s3nm1f1f1; para conectarnos a dicha red tendríamos que escribir:

iwconfig wlan0 essid PRIVADO key N03ntr3s3nm1w1f1

Por último, aunque estemos conectados a la red inalámbrica en cuestión, tenemos que solicitarle una ip válida que nos permita navegar y comunicarnos con el resto de elementos de dicha red; es por ello que es necesario usar la herramienta dhclient.

dhclient wlan0

Si somos muy vagos y no queremos hacer el proceso a mano, podemos intentar sintetizar todo lo que hemos visto dentro de un script; un script que dependiendo de nuestro nivel de vagancia, puede ser más completo o no. Una opción podría ser ésta:

  1. #!/bin/bash
  2. ifconfig wlan0 up
  3. iwlist wlan0 scan > /tmp/ESSID.txt
  4. echo "Escoja un ESSID por favor:"
  5. cat /tmp/ESSID.txt |grep 'ESSID'
  6. read SELECCION
  7. echo "Introduzca la password"
  8. read CONTRASENA
  9. iwconfig wlan0 essid ${SELECCION} key ${CONTRASENA} 2&>1 > /dev/null
  10. if [ $? -eq 0 ];
  11. then
  12.         dhclient wlan0 2&>1 > /dev/null
  13.         if [ $? -eq 0];
  14.         then
  15.                 echo "CONEXION EXITOSA"
  16.         else
  17.                 echo "Se ha conectado a la wifi, pero no ha recibido ip"
  18.         fi
  19. else
  20.         echo "No ha podido establecerse la conexion con: ${SELECCION}. Revise los parametros introducidos"
  21. fi
  22. rm /tmp/ESSID.txt


Método sencillo pero orientado a conectase siempre a la misma red

Si en cambio queremos tener todo más orientado a conectarnos siempre a la misma red inalámbrica y queremos optar por alternativas todavía más sencillas que la anterior (aún con el script), podemos optar por usar una herramienta muy útil llamada wpasupplicant, herramienta que si bien no está instalada por defecto en el sistema como ocurría con la alternativa anterior, es muy útil en entornos domésticos o "fijos" en los que sabemos que siempre vamos a conectarnos a la misma red y no queremos ser preguntados por el sistema cada vez que nos queramos conectar a dicha red. Para ello lo primero que necesitaríamos hacer sería instalar la herramienta en cuestión, la cual afortunadamente se encuentra en los repositorios del sistema con lo que simplemente habría que escribir:

apt-get install wpasupplicant

La instalación apenas dura unos segundos, tras los cuales podemos prepararlo todo para que conectarnos automáticamente. Esto lo lograremos gracias al comando wpa_passphrasse, que nos creará una salida de datos que habría que volcar en un fichero de configuración llamado wpa_supplicant.conf, alojado en /etc/wpa_supplicant; usando como base el anterior ESSID y la anterior contraseña, podríamos crear el siguiente ejemplo:

wpa_passphrase PRIVADO N03ntr3s3nm1w1f1 > /etc/wpa_supplicant/wpa_supplicant.conf

Al tener dhclient instalado por defecto en el equipo, y como éste por defecto comprueba la existencia de un fichero wpa_supplicant.conf; durante cada arranque se conectaría automáticamente a la red inalámbrica en caso de que ésta fuese alcanzable; si deseasemos conectarnos manualmente a la red inalámbrica mediante wpa_supplicant, podríamos ejecutar este comando:

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

Podríamos también usar como base el script anterior para hacer que en caso de realizarse una conexión exitosa con una wifi en concreto, tengamos la opción de guardar el ESSID y sus credenciales; algo que quedaría así:

  1. #!/bin/bash
  2. ifconfig wlan0 up
  3. iwlist wlan0 scan > /tmp/ESSID.txt
  4. echo "Escoja un ESSID por favor:"
  5. cat /tmp/ESSID.txt |grep 'ESSID'
  6. read SELECCION
  7. echo "Introduzca la password"
  8. read CONTRASENA
  9. iwconfig wlan0 essid ${SELECCION} key ${CONTRASENA} 2&>1 > /dev/null
  10. if [ $? -eq 0 ];
  11. then
  12.         dhclient wlan0 2&>1 > /dev/null
  13.         if [ $? -eq 0];
  14.         then
  15.                 echo "CONEXION EXITOSA. Desea guardar las credenciales usadas para futuras conexiones?[s/n]"
  16.                 read RESPUESTA
  17.                 if [ "$RESPUESTA" == "s" ];
  18.                 then
  19.                         wpa_passphrase ${SELECCION} ${CONTRASENA} >> /etc/wpa_supplicant/wpa_supplicant.conf
  20.                         echo "Credenciales guardadas en el equipo"
  21.                 else
  22.                         echo "Has seleccionado NO"
  23.                 fi
  24.         else
  25.                 echo "Se ha conectado a la wifi, pero no ha recibido ip"
  26.         fi
  27. else
  28.         echo "No ha podido establecerse la conexion con: ${SELECCION}. Revise los parametros introducidos"
  29. fi
  30. rm /tmp/ESSID.txt

Con esto tendríamos una solución que combinaría la flexibilidad de iwlist junto con la comodidad de wpa supplicant. Estos scripts han sido testeados en Debian y Ubuntu pero no tendriais que tener problemas en el resto de distribuciones.

Espero que os haya resultado útil.

Saludos.

miércoles, 16 de marzo de 2016

Auditoría general de Linux con Tiger

Siguiendo con la línea del anterior artículo, es decir, con el tema de las auditorías, hoy quiero veniros con una utilidad que reúne una serie de herramientas conocidas, entre ellas john the ripper, que trabajan en conjunto con el fin facilitarnos la vida. Es cierto que las herramientas especializadas que se usan única y exclusivamente para una tarea en concreto, suelen ofrecer resultados mucho más precisos y que generalmente son las más deseables ¿Pero quien no quiere una herramienta que puedan englobar las características de varias herramientas de auditoría para hacer una revisión global del sistema? Una de las virtudes de este tipo de opciones es que al englobar tantas funciones puede ejecutar tareas que de otra manera podríamos haber pasado por alto, como por ejemplo la revisión del fichero /etc/passwd o la seguridad de nuestra conexión ssh., con lo que puede ser interesante darle una oportunidad; el nombre de la utilidad de la que hoy quiero hablaros sería Tiger.

Tiger_portada


Al igual que otras muchas herramientas de auditoría (por no decir que prácticamente todas), esa una herramienta de doble filo que puede usarse para comprobar la seguridad de nuestro sistema o para comprobar vulnerabilidades en éste. El objetivo de Tiger sería revisar uno por uno cada fichero de configuración y de contraseñas; es decir no revisa puertos de red ni busca vulnerabilidades asociadas con las versiones de los diferentes softwares... Aún así no penséis por ello que es una herramienta incompleta, es más, con una revisión probablemente encontrareis varios puntos que, si bien probablemente no sean de por sí vulnerabilidades graves, sí que pueden ser peligrosos y pueden ser usados para hacer daño.

Para poder sacar partido a este animal, habría que pasar a instalarlo primero, si bien hay que tener en cuenta que instalará un buen número de aplicaciones relacionadas con Tiger, tales como john the riper (como he comentado antes) o Tripwire, con lo que no solo ocuparemos cierto espacio en el disco, sino que la instalación en sí llevará cierto tiempo.  Su instalación es extremadamente sencilla, pues se realiza desde los propios repositorios; por ejemplo en Debian o derivados se usaría este comando:

apt-get install tiger

La instalación requerirá seguir una serie de pasos relacionados con Tripwire, pues para funcionar necesita que instalemos dos claves (con sus respectivas contraseñas): Una clave local que se usa cifrar la información del estado de los archivos y una clave del sitio que se usa para cifrar archivos de configuración; estas claves no serían usadas por nosotros, pero sí que sería necesario instalarlas para asegurarnos de que tiger funcionará a la perfección.

Con tiger instalado, podríamos pasar a auditar nuestro sistema... Es recomendable saber que tiger puede realizar informes en texto plano o en html; Aquí uno debe decidir, pero personalmente me parece más cómodo el informe en html debido a su facilidad de lectura de cara al usuario final, si bien esto depende de los gustos de cada uno; si queremos realizar una revisión que genere un informe "normal", tendríamos que ejecutar tiger "a secas":

tiger

En cambio, si deseamos optar por la visión más visual, tendríamos que acompañar al comando del parámetro -H, tal que así:

tiger -H

Dependiendo de la cantidad de archivos de configuración que tengamos, usuarios, procesos activos, etc... La duración de la auditoría variaría... A mí por ejemplo en un entorno recién instalado me tomó 5 minutos, pero si ejecutásemos el programa en un equipo al que se le haya dado más uso probablemente tomaría más tiempo.

Cualquier informe que generemos, tenga el formato que tenga, se volcaría sobre el directorio /var/log/tiger; cada informe tendría el formato:

security.report.hostname.día.mes.año-hora.extensión

Aquí tendríamos dos opciones; si fuese un fichero de texto plano se podría leer directamente mediante algún editor de texto, pero si tratasemos un html podríamos jugar con él y hacerlo visible en nuestro servidor web para poder leerlo con más facilidad. Imaginemos que tenemos un arhivo llamado security.report.debianserver.150316-20:18.html, podríamos hacerlo visible en nuestro servidor mediante el siguiente procedimiento:

  1. mkdir /var/www/html/tiger
  2. cp /var/log/tiger/security.report.debianserver.150316-20:18.html /var/www/html/tiger/informe.html
  3. chmod 444 /var/www/html/tiger/informe.html

Ahora únicamente con escribir la URL de nuestro servidor web seguido de /tiger/informe.html, podríamos visualizar el informe con comodidad desde nuestro navegador; ahora solo quedaría revisarlo y ver en qué aspectos podemos mejorar nuestra seguridad.

Espero que os haya resultado útil.

Saludos.