Información blog

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

viernes, 29 de mayo de 2015

Cómo instalar Nagios en Debian8

Más de una vez, uno puede llegar a escuchar preguntas tales cómo: ¿Existen una herramienta capaz de ver el estado de otros equipos remotamente? o ¿Existe alguna forma de supervisar desde un mismo punto diferentes servicios y así evitar el tener que ir servidor por servidor haciendo los chequeos pertinentes? Esta necesidad es muy real en entornos grandes, y la mayoría de los que trabajan en el sector de la tecnología o son simplemente unos amantes de ésta, piensan en la misma herramienta: Nagios.

Existen multitud de herramientas parecidas a ésta (cómo por ejemplo icinga) pero ésta ha sido la primera de todas y la más conocida; todas poseen sus pros y sus contras y es difícil decantarse por una pues todas afirman ser mejores que el resto. Aún así, Nagios ciertamente ha demostrado ser un software estable capaz de combinar facilidad de configuración con fiabilidad, y si a eso le sumamos su fama, es probablemente la mejor opción a la hora de escoger un software de este tipo.

En este caso he optado por instalarlo en un Debian8 (Jessie) sin entorno gráfico alguno. Es perfectamente posible instalarlo en un entorno con interfaz gráfica, pero lo más común es no encontrarse con este tipo de situaciones con lo que es recomendable acostumbrarse a instalarlo sin ayuda gráfica alguna para evitar dificultades en el futuro.

Para la instalación de Nagios es imprescindible poseer ciertas herramientas instaladas de antemano:

  1. php y Apache2; Estas dos herramientas serán las que nos faciliten su gestión vía web, sin éstas la gestión de esta herramienta puede tornarse realmente dificultosa.
  2. Build-essential: Este paquete contiene las herramientas indispensables para la manipulación de paquetes, entre otros está uno que será indispensable para la instalación: un compilador llamado gcc.
  3. libdg-tools: Se trata de un conjunto de librerías que facilita al código fuente el trazado de líneas, el insertado de imágenes y otras tareas especialmente útiles en entornos web.
La mejor forma en la que uno puede asegurarse que se poseen todos los requisitos sería insertando el siguiente comando, el cual lo podéis copiar y pegar directamente en caso de trabajar en un entorno gráfico:

  1. apt-get install php5 build-essential apache2 libgd2-xpm-dev libapache2-mod-php5

Una vez comprobado que se cumplen los requisitos, tocaría pasar a la instalación del programa en cuestión. Para ello habría que hacer uso del comando wget, el cual permite descargar un archivo directamente desde la propia consola. En este caso se ha hecho la instalación de nagios-4.0.4, pero bien podría aplicarse a otra versión siempre y cuando se respete la sintaxis:

  1. cd /tmp/
  2. wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-4.0.4.tar.gz
  3. wget http://nagios-plugins.org/download/nagios-plugins-2.0.tar.gz

En este caso he realizado el comando desde la carpeta /tmp/ ya que el fichero se almacena en el directorio desde el cual se lanza el comando, con lo que en caso de querer guardarlo en otra carpeta habría que optar por otra ruta. Una de las "bondades" del directorio tmp es que su contenido es vaciado automáticamente al apagar o reiniciar el equipo, con lo que gracias esta medida nos aseguraremos que los ficheros comprimidos que hemos descargado se eliminarán automáticamente al siguiente reinicio.

Ahora sería el turno de preparar un usuario y un grupo; ambos especialmente preparados para funcionar con el software en cuestión, con lo que lo ideal sería optar por nombres intuitivos que nos permitan relacionar el software con el usuario, algo cómo nagios o algún equivalente. En este caso voy a usar ejemplos genéricos cómo $usuario y $grupo para realizar las distinciones pero por ejemplo un usuario y grupo válidos podrían ser nagios y nagios El proceso de creación del usuario y del grupo sería el siguiente:

  1. useradd $usuario
  2. groupadd $grupo
  3. usermod -a -G $grupo $usuario

Los dos primeros comandos sirven para crear el usuario y el grupo respectivamente, mientras que el tercero sería para asociar el grupo con el usuario.

Con todos los preparativos hechos, sería el turno de instalar Nagios. Para ello, en la carpeta en la que hemos descargado los dos ficheros comprimidos, habría que pasar éstos primero por la descompresión. Para ello habría que usar estos dos comandos:

  1. tar zxvf nagios-4.0.4.tar.gz
  2. tar zxvf nagios-plugins-2.0.tar.gz

Esto ha dado cómo resultado dos nuevas carpetas: nagios-4.0.4 y nagios-plugins-2.0. Ahora sería el turno de instalar el contenido de la primera carpeta; el proceso es algo más complicado que los famosos apt-get o dpkg; en este caso hay que ir paso a paso para configurar, compilar y finalmente instalar el software.

El primer paso es configurar el paquete antes de su compilación; Para ello habría que dirigirse a la carpeta nagios-4.0.4 y usar el siguiente comando, en el cual cómo podréis apreciar se incluyen tanto el usuario cómo el grupo:

  1. ./configure --with-nagios-group=$usuario --with-command-group=$grupo -–with-mail=/usr/bin/sendmail


El proceso de configuración suele llevar algo de tiempo, dependiendo de la potencia del equipo. Al finalizar el proceso, deberíais observar una pantalla en la que muestra la información necesaria para acceder al configurador web, tal que así:



Con la aparición de dicha pantalla, dariamos por finalizado el proceso de configuración, dando paso al proceso de compilación e instalación del paquete mediante el comando make. En este caso he agrupado todos los comandos necesarios juntos, con el fin dejar todos los comandos agrupados. Cómo veréis, hay tres lineas que no tienen nada que ver con el comando make. La razón de su existencia es que sin estas carpetas ni sin ese fichero, la instalación del webconf no funcionará.

  1. make all
  2. make install
  3. make install-init
  4. make install-config
  5. make install-commandmode
  6. mkdir /etc/httpd
  7. mkdir /etc/httpd/conf.d
  8. touch /etc/httpd/conf.d/nagios.conf
  9. make install-webconf


Aún con todo esto, aquí es importante hacer una pequeña pausa, pues cómo os podreis imaginar, el fichero nagios.conf que hemos creado no tiene uso alguno, y por mucho que hagamos bien los siguientes pasos, la interfaz web no funcionará. La solución es simple: añadir el contenido nagios.conf al fichero apache.conf y borrar la carpeta httpd que hemos creado antes pues no nos va a servir de nada. Además es necesario habilitar los cgi, mediante el comando a2enmod cgi ya que sino no os cargará los modulos. Esto se puede hacer con los siguientes comandos:


  1. cat /etc/httpd/conf.d/nagios.conf >> /etc/apache2/apache2.conf
  2. rm -R /etc/httpd/
  3. a2enmod cgi

Con todos los módulos instalados y preparados (a falta de los plugins) es necesario copiar la carpeta eventhandlers alojada en la carpeta contrib (la cual se encuentra dentro de la carpeta en la que nos encontramos ahora). Además, mediante el uso del comando chown, cambiariamos las propiedades de la carpeta para que perteneciese al usuario y grupo que hemos creado antes. Por último usaríamos un comando para revisar que el fichero nagios.cfg funciona correctamente (en un principio no deberiais topar problema alguno) y solo quedaría iniciar el servicio nagios.

  1. cp -R contrib/eventhandlers/ /usr/local/nagios/libexec/
  2. chown -R $usuario.$grupo /usr/local/nagios/libexec/eventhandlers
  3. /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
  4. /etc/init.d/nagios start

Aún así, nagios aún no estaría listo para ser usado. El primer motivo es que nagios no posee ningún usuario configurado para poder manejar la interfaz web. Para lograr dicho objetivo habría que asignarle un usuario cómo por ejemplo nagiosadmin, cuya única función es brindarte acceso a la interfaz web. Al crear dicho usuario nos preguntará también sobre la contraseña que deberemos asignarle.

  1. htpasswd –c /usr/local/nagios/etc/htpasswd.users nagiosadmin

El segundo motivo, pero no menos importante, es que todavía no hemos instalado los plugins ni hemos preparado el propio nagios para iniciarse automáticamente en el arranque. Comencemos con la instalación de los plugin. El proceso es bastante parecido al aplicado ahora pero bastante simplificado. 

Para empezar sería necesario posicionarse en la carpeta nagios-plugins-2.0. Aquí también hay que "configurar" los paquetes con el usuario y grupo que hemos creado anteriormente para después compilarlos e instalarlos, el proceso entero se basa en tres comandos, dos de ellos muy comunes:

  1. ./configure --with-nagios-user=$usuario --with-nagios-group=$grupo
  2. make
  3. make install

Ahora mismo todo estaría preparado para funcionar, pero lamentablemente, el servicio nagios no está configurado para ser iniciado automáticamente en el arranque; Cosa muy molesta pues cada vez que se reinicie el equipo habría que iniciar a mano el servicio. Afortunadamente esto se puede solventar añadiendo el servicio al arranque del init de debian8 mediante el comando:

  1. ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Lo único que quedaría por hacer sería reiniciar el equipo y acceder a la siguiente URL:

ip_servidor/nagios

Al acceder a dicha URL os debería aparecer un popup como el que os voy a mostrar ahora:


Las credenciales que deberemos de introducir serían las mismas que hemos creado con el comando htpasswd; con las cuales podríamos disfrutar del software en cuestión.

Espero que os haya resultado útil.

Saludos.

lunes, 25 de mayo de 2015

Permisos, propiedad y grupos en Linux

Una de las cosas que caracteriza a los sistemas Linux, es la gestión de los permisos que poseen y la importancia que le dan al hecho de que los administradores poseen unos permisos x, los dueños otros, los grupos otros, etc... Esa gestión puede parecer rígida en un principio, pues a veces tienes que cambiar de usuario o hacer uso del famoso "sudo", pero también asegura que sólo los usuarios pertinentes puedan leer, escribir o ejecutar el archivo pertinente. La gestión de permisos se pueden hacer de dos maneras:
  1. Desde la interfaz gráfica.
  2. Desde el comando chmod y en caso de necesidad, chown.
La interfaz gráfica hoy en día es muy intuitiva y no se necesitan apenas conocimientos para cambiar los permisos; simplemente se basa en acceder a las propiedades de un fichero. Fácil y sencillo. Este sería un ejemplo de una gestión de permisos en un entorno gráfico KDE:


Para entender cómo funciona chmod(change mode) primero habría que entender cómo funcionan los permisos. Existen tres tipos de permisos perfectamente combinables entre sí: Lectura, escritura, ejecución. El hecho de carecer de permisos de lectura haría que no se pudiese consultar el fichero, el permiso de escritura consiste en la capacidad de modificar un fichero y el permiso de ejecución consiste en la posibilidad de ejecutar el fichero o programa en cuestión. 

Además no se otorgan permisos exclusivamente a un usuario en concreto. sino que se les otorgarían a tres "grupos". El propietario, el grupo al que pertenece y el resto de usuarios. 

Para modificar los permisos existen dos opciones: La modificación mediante el uso del sistema octal y la modificación mediante caracteres. 


Modificación mediante el sistema octal

El sistema octal parte del sistema binario cómo base y cada número representaría una serie de permisos en concreto, números que oscilarían del 0 al 7, siendo el número 0 el que no otorga ningún permiso y el número 7 el que da los máximos permisos. He aquí una tabla muy explicita que muestra exactamente qué permisos otorga cada número.


Además, basándonos en lo que he descrito antes, es decir, en la existencia de 3 "grupos", cada uno de estos tendría sus propios permisos, con lo que a la hora de otorgar permisos de forma octal, 000 equivaldría a la denegación de permisos total a todos los grupos y usuarios mientras que 777 equivaldría al control total del fichero a todos. El primer dígito representaría al propietario del archivo, el segundo al grupo y el tercero al resto, con lo que con esa información podríamos mostrar los siguientes ejemplos:

Para darle control total al propietario y permisos de lectura y ejecución tanto a su grupo cómo al resto de usuarios:
  1. chmod 755 archivo.txt
Para darle permisos de lectura y ejecución al propietario, permisos de lectura a su grupo, y ningún permiso al resto sería:
  1. chmod 540 archivo.txt
Para darle control total al propietario y negarles cualquier tipo de acceso al resto sería:
  1. chmod 700 archivo.txt

Los ejemplos pueden ser numerosos, pero mediante la tabla y los ejemplos explicados podeis poseer de una base con la que aplicar el comando chmod a vuestras necesidades.


Modificación mediante caracteres

Esta modificación es más cómoda en opinión de algunos, pues no requiere realizar cálculos mediante el sistema octal y es bastante intuitivo; Aún así, en mi opinión ambos son igual de útiles. Este sistema se caracteriza por el uso de caracteres y modificadores.

Los modificadores serían:

+ para añadir un permiso.
-  para eliminar un permiso.
= para establecer un permiso, sustituyendo los ya establecidos.

Mientras que los caracteres que seguirían estos modificadores serían:

r  el cual equivaldría al permiso de lectura.
w el cual equivaldría al permiso de escritura/modificación.
x  el cual equivaldría al permiso de ejecución.

Además se puede poner el destinatario del cambio de permiso. Por defecto los destinatarios serían todos en caso de no poner destinatario alguno; en cambio, se pueden especificar los destinatarios mediante unos parámetros en concreto:

u Equivaldría al propietario (user).
g Equivaldría al grupo (group)
o Equivaldría al resto de usuarios (others).
a Equivaldría a todos (all), aunque de por sí no sería necesario, pues ya se usa por defecto.

Con esta información podríamos construir los siguientes ejemplos:

Para añadir permisos de ejecución a todos, tanto propietario, cómo el grupo del propietario, cómo al resto de usuarios:
  1. chmod +x archivo.txt
Para eliminar los permisos de escritura del propietario y añadir permisos de ejecución tanto al grupo, cómo al resto de usuarios:
  1. chmod u-w,go+x archivo.txt
Para establecer permisos de lectura ,escritura y ejecución al propietario, eliminar los permisos de escritura al grupo, y establecer permisos de lectura al resto de usuarios:
  1. chmod u=rwx,g-w,o=r archivo.txt

Cómo podéis ver, a partir de que se sabe para qué sirve cada carácter, combinarlos resulta fácil y cómodo, a partir de aquí sería probar las distintas combinaciones para ajustar los permisos de los ficheros a nuestras necesidades.


Modificación de propietario y del grupo

Hemos visto cómo poder modificar los permisos del propietario y del grupo pero... ¿Cómo podemos cambiar éstos? Estos parámetros se pueden modificar con facilidad mediante el comando chown (change owner). El comando posee la siguiente estructura:

  1. chown propietario.grupo archivo.txt

Con lo que por ejemplo, si tuviésemos un archivo llamado prueba.txt que fuese propiedad del usuario y grupo root, y deseásemos que pasase a ser propiedad del usuario invitado y del grupo visitante, habría que escribir:

  1. chown invitado.visitante prueba.txt


Con esto ya podríamos tanto modificar los permisos de un archivo cómo cambiar su propietario y grupo.

Espero que os resulte útil.

Saludos.

viernes, 22 de mayo de 2015

Cómo cifrar un fichero con gpg

Siguiendo con la línea del cifrado, en este caso voy a hablar de un sistema de cifrado de archivos llamado gpg. GPG (Gnu Privacy Guard) es un clon libre de PGP (Pretty Good Privacy) que funciona bajo Linux, que tiene cómo función cifrar y descifrar archivos y mensajes. Carece de interfaz gráfica, pero sus funciones básicas se puede recordar con bastante facilidad. Dependiendo de las necesidades de uno pueden cifrar los ficheros de dos formas: de forma simétrica o asimétrica.


Cifrado gpg simétrico

El cifrado simétrico es el más simple de los dos; se basa en proteger un mensaje con una sola clave que se encargará de las tareas de cifrado y descifrado. Eso quiere decir que se usará la misma clave para una tarea y otra, lo cual en algunos casos es útil, si bien hoy en día se está optando más por el cifrado asimétrico porque ha demostrado ser más seguro. De todas formas, su simplicidad y su facilidad de implementación la convierten en una opción de cifrado muy cómoda para muchos, y por ello algunos la siguen usando. Para cifrar un fichero de texto con un cifrado simétrico, simplemente habría que escribir:

  1. gpg --symmetric fichero.txt

Al teclear dicho comando debería de preguntarnos por una contraseña, la cual servirá para proteger el archivo en cuestión. Dicha contraseña debe ser robusta con el fin de mantener la confidencialidad de dicho archivo, con lo que es recomendable que esté compuesta por mayúsculas, minúsculas, números y caracteres especiales. Tras finalizar el cifrado, veréis que se ha creado un archivo con el mismo nombre y con la extensión .gpg; ese será el archivo cifrado. Usaré cómo ejemplo un txt ficticio al que he llamado mensaje.txt. Dicho txt posee el siguiente contenido:


El mensaje en cuestión se ve perfectamente legible y sin ningún problema. Ahora habría que pasar al proceso de cifrado mediante el comando mencionado; cómo podéis ver en la siguiente imagen, ahora tenemos dos ficheros: mensaje.txt y mensaje.txt.pgp.


Ahora para comprobar que efectivamente el fichero está cifrado sería tan fácil cómo consultar su contenido mediante el comando cat. El cual os mostraría algo ilegible parecido a lo siguiente:


El contendido en cuestión, sólo se podría descifrar mediante la clave que hemos usado para cifrar el archivo en cuestión, aunque para ello habría que usar un comando especial que sería este:

  1. gpg --decrypt - o fichero.txt.gpg fichero.txt

Cómo podeis ver, primero habría que poner el fichero cifrado y después el fichero de salida que se creará tras el descifrado. Tras teclear dicho comando tocaría introducir la contraseña antes comentada, la cual en caso de ser correcta debería crear el fichero de salida en cuestión; dicho fichero sería perfectamente legible. Basándonos en el ejemplo anterior sería:



Cifrado gpg asimétrico


Este tipo de cifrado es el mismo que mencioné anteriormente a la hora de crear una clave precompartida RSA,. Se basa en la creación de una clave pública y privada: la pública sería la de cifrado y la privada la de descifrado. Ambas claves están relacionadas entre sí pero el hecho de conocer la clave pública no te hace conocer la privada, añadiendo una capa extra de seguridad a la comunicación, pues en este caso existen dos claves y no una cómo en el caso de la simétrica. 


Para cifrar un mensaje de forma asimétrica se necesita primero crear las claves de cifrado gpg. Para ello se usaría el siguiente comando:

  1. gpg --gen-key

Dicho comando se encargaría de crear la clave en cuestión, pero a diferencia de con la clave simétrica, en este caso es necesario seguir una serie de pasos. Lo primera pregunta que os aparecerá cuando introduzcáis el comando, será el tipo de cifrado deseado: DSA y ElGamal, DSA o RSA; En general se escoge la opción por defecto; DSA y ElGamal.


A raíz de realizar la elección, se os preguntará sobre el tamaño de la clave asimétrica, que puede oscilar entre 1024 y 4096; Por defecto está configurado para que se genere una clave de 2048 (un tamaño lo suficientemente grande para crear una clave robusta) pero este valor puede ser modificado. A modo de recomendación personal, recomiendo no escoger el tamaño mínimo, pues ha demostrado que no es del todo seguro.


Luego al tiempo de validez de la clave. El tiempo, establece la cantidad de días que la clave va a ser válida, pero si se quiere, la clave puede tener una validez infinita, cosa que ya está establecida por defecto y que recomiendo mantener como está.


Por último, habría que introducir los datos personales de uno, que harán de identificador de la clave; Ese identificador ayudará a uno a identificar la clave en cuestión, y el valor más importante de éste sería el Alias o Comentario. Además, también habrá que introducir la contraseña que protegerá la clave en cuestión, que al igual que he comentado con la clave simétrica, tiene que ser robusta.


Con estos datos introducidos, ahora tocaría esperar un rato a que se genere la clave. Habrá un momento en el que os mostrará un mensaje parecido a este:


Esto se debe a que para cifrar el archivo se necesita que el ordenador realice algunas tareas que pongan a trabajar sus discos y sus tarjetas de red; Aquí es difícil dar consejos... En mi caso abrí otra terminal y empecé a realizar tareas, tales cómo: hacer pings a diferentes sitios, actualizar los repositorios mediante apt-get update, navegar por internet (en caso de tener interfaz gráfica es el método más rápido y eficaz), ejecutar algunos scripts ficticios con el único fin de poner a trabajar el equipo, etc... Tras unos pocos minutos, ya deberíais tener la clave generada en un formato parecido a este:



Ahora tocaría generar la clave. Para ello el comando varía ligeramente del usado para el cifrado simétrico. 

  1. gpg --encrypt -r alias fichero.txt

Allí donde he puesto alias, habría que introducir el alias que hemos introducido para crear la clave. Yo en mi caso he hecho una clave poniendo cómo Alias ivan, con lo que si quisiésemos cifrar el fichero, mensaje.txt que hemos usado en la anterior prueba habría que escribir:


Cómo habréis podido comprobar, no pide clave alguna cifrar el archivo, ya que se está usando la clave que asimétrica que hemos generado. Para descifrarlo se usaría el mismo comando que hemos usado antes para descifrar el cifrado simétrico, con la diferencia que la contraseña que hay que introducir es la misma que hemos introducido en el proceso de generación de la clave asimétrica:

  1. gpg --decrypt - o fichero.txt.gpg fichero.txt



Importar y exportar la claves asimétricas

El proceso que acabo de realizar, lo he hecho dentro del mismo equipo; pero cómo podríamos hacerlo en otros? Es decir: ¿Cómo podemos hacer que otro equipo que tenga Linux instalado (digo Linux porque gpg va instalado por defecto) sea capaz de leer o de cifrar archivos con la misma facilidad que nosotros? Para ello es necesario exportar e importar las claves en cuestión, lo cual es muy sencillo.

Comencemos con la exportación de claves. La exportación de una clave consiste en preparar esta para ser desplazada a otro equipo. En este caso poseemos dos claves para exportar: Una pública y otra privada. Para exportar la clave pública habría que escribir:

  1. gpg --export -a alias > public.key

En este comando lo que haríamos sería coger la clave pública y volcarla en un fichero llamado public.key, el nombre del fichero destino es opcional, si bien tiene que tener la extensión .key; Por ejemplo, para mi caso particular tendría que escribir:


Para la clave privada, aunque el comando es parecido, varía ligeramente, pues hay que especificar que se trata de la clave privada. El comando sería:

  1. gpg --export-secret-key -a alias > private.key

Es decir, que en este caso, habría que poner especificar que se trata de una clave secreta/privada, para que el sistema reconozca que se quiere exportar la clave privada. Esta clave, private.key, debe de ser guardada en un lugar seguro pues será la que tenga el poder de descifrar los mensajes. En mi caso en particular el comando sería:


Ambos .key, pueden ser almacenados en un USB y transportarlos a la máquina que nosotros queramos. Ahora bien, con tener los .key en otro equipo no basta para que éste sea capaz de cifrar/descifrar los mensajes mediante dichas claves. Hay que importarlas a la base de datos gpg de nuestro equipo. 

Para importar cualquiera de las dos claves bastaría con escribir:

  1. gpg --import clave.key

Eso quiere decir que el comando bastaría tanto para hacer el import de public.key cómo de private.key. Aplicándolo a las claves que hemos generado sería:

y


Espero que os resulte útil.

Saludos.

lunes, 18 de mayo de 2015

Cómo acceder por ssh de forma segura

La gran mayoría de las personas que hayan usado Linux alguna vez en su vida, han conocido las virtudes que ofrece el poseer acceso por ssh a su máquina. Desgraciadamente la configuración por defecto, aunque es bastante segura, no es del todo deseable, por dos motivos:

  1. Permite que root pueda acceder mediante dicho acceso, algo completamente contraproducente.
  2. La seguridad que te ofrece, depende por completo de la contraseña; Una contraseña que puede ser robada o que puede intentar adivinarse mediante los famosos ataques de fuerza bruta.
Por ello vamos a intentar crear un acceso abierto (es decir, que no sea restrictivo y engorroso, y que le permita a uno acceder desde donde quiera) y seguro, eliminando esos dos problemas potenciales que acabo de describir.

Imposibilitar el acceso por ssh a root

En las últimas versiones están empezando a imposibilitar el acceso, pero es algo que han empezado a hacer desde hace relativamente poco. He de suponer que el motivo por el que hasta ahora lo dejaban abierto era que deseaban dar al usuario la mayor libertad posible para hacer lo que deseen, y si hablamos de un equipo de pruebas o que no va a estar las 24 horas encendido (cosa que ocurre con los servidores) podría estar justificado, aunque no del todo.

Afortunadamente, el impedir que root sea capaz de acceder por ssh es muy sencillo: Solamente hay que acceder con un usuario con permisos de administrador a la carpeta /etc/ssh y entrar el fichero sshd_config. Este fichero almacena las reglas generales del servicio ssh, incluyendo la dirección de escucha, puerto (por defecto el 22), etc... Entre estas reglas hay una que nos interesa especialmente que es: PermitRootLogin. Puede mostrarse de dos formas:






El segundo caso es el que se está usando en las versiones más recientes, tales cómo Debian 8 o versiones posteriores a Ubuntu 14.04 (ésta inclusive). La opción without-password significa que permite la autenticación de root, pero que éste no puede autenticarse mediante una contraseña. Esto para la mayoría de los casos estaría bien, pero yo soy partidario de no permitir que root acceda bajo ningún concepto desde fuera, con lo que lo más recomendable sería modificar esa línea, ya esté escrita de una manera u otra, para dejarla así:




Ahora sólo quedaría reiniciar el servicio ssh mediante el comando /etc/init.d/ssh restart, aplicando así los cambios realizados. Ahora desde cualquier herramienta de acceso por ssh, ya sea una terminal de Linux o la herramienta putty, probaríamos a acceder remotamente con el usuario root. El mensaje de respuesta debería ser el siguiente:



Preparar el servidor para poder autenticarse únicamente por RSA

Ahora sería el turno de preparar una autenticación que no sea sea la contraseña plana. Existen varios métodos, pero el preferido por muchos es mediante una clave pre-compartida RSA, compuesta por una clave pública y una privada. La pública será aquella que se almacenará en una carpeta especifica dentro del directorio personal de un usuario (/home/usuario) o dentro del directorio root, mientas que la privada será la "llave" de acceso que sólo la podrán tener aquellos que deseemos que puedan tener acceso al servidor. Dicha llave solo podrá usarse para acceder con usuarios que posean la clave pública almacenada. Cómo esto puede sonar un poco complicado, vayamos paso a paso:

Este proceso se puede hacer con la herramienta de terceros putty, o desde una consola, y aunque el proceso en putty es mucho más gráfico, voy a explicar el proceso para hacerlo desde consola, ya que el concepto es el mismo y puede resultar un poco menos intuitivo en ésta; eso sí, la clave privada generada en Linux no puede usarse en putty ni viceversa, con lo que tenedlo en cuenta a la hora de generar la clave. Es recomendable hacer todo el proceso con un usuario que posea permisos de administrador para evitar complicaciones, aunque se podría hacer también con un usuario normal.

El comando que vamos a usar para crear ambas claves es el ssh-keygen. El comando es tan sencillo que no requiere parámetro alguno para funcionar es decir que con escribir el comando a secas funcionaría, pero cómo deseamos que la clave sea específicamente rsa y queremos que sea lo más robusta posible, escribiremos:

ssh-keygen -t rsa -b 4096


Este comando en concreto os generará una clave RSA de 4096 bytes (la más segura de todas) y os preguntará el directorio en el que deseáis alojar las claves; por defecto carpeta_usuario/.ssh/; y una contraseña que proteja la clave privada (opcional, pero recomendable). al desplazarnos al directorio en cuestión deberíamos ver los siguientes archivos:



La primera sería la clave privada, mientras la otra sería la pública que iría al servidor ssh. Con desplazar la clave pública al servidor no basta sino que también habría que modificar (o crear en caso de no existir) el fichero authorized_keys, alojado en /carpeta_usuario/.ssh/ mediante el siguiente proceso:

  1. mdkir /home/ivan/.ssh #nos aseguramos que la carpeta .shh existe
  2. touch authorized_keys #creamos el fichero authorized_keys en caso de que no exista
  3. cat id_rsa.pub > /home/ivan/.ssh/authorized_keys #copiamos el contenido de id_rsa.pub a authorized keys

Con esto ya estaría el servidor en cuestión preparado para recibir una conexión con autenticación RSA, si bien actualmente están activos ambos métodos de acceso, el de contraseña y éste. Esto ya es completamente opcional, pero en caso de querer que sólo se pueda acceder mediante la clave RSA habría que dirigirse al fichero /etc/ssh/sshd_config y modificar el parámetro PasswordAuthentication. Por defecto dicho parámetro debería aparecer así:


Solamente con quitar el carácter #, modificar el valor a no y reiniciar el servicio ssh, se eliminaría la posibilidad de introducir la contraseña, dejando cómo única posibilidad el uso de la clave RSA.

Probando el acceso mediante clave RSA


Para acceder por consola es necesario almacenar en la carpeta /home/usuario/.ssh o /root/.ssh (dependiendo del usuario con el que se esté logueado) y copiar el fichero id_rsa a dicha carpeta. En caso de no encontrarse dicho fichero, y tener deshabilitado el acceso con contraseña, debería mostraros el siguiente mensaje:




En cambio, si se posee la clave correctamente almacenada y conocemos la password (en caso de haberle puesto) de la clave privada, obtendremos la siguiente pantalla:



Saludos.

sábado, 16 de mayo de 2015

Cómo crear un servidor DNS con bind9

El servicio DNS(Domain Name System) es usado por todos los internautas a diario. Su utilidad es simple, pero indispensable en la sociedad actual: Traducir las direcciones ip a nombres de dominio y viceversa. Recordar una dirección ip y asociarla a un sitio en concreto resulta difícil, con lo que el DNS elimina esa dificultad que conlleva, además de que la ip del sitio puede cambiar en cualquier momento (debido a las circunstancias que sean) y no sabríamos cómo llegar sin la ayuda de este servicio. Obviamente éste no es mágico; posee una base de datos que intenta relacionar la dirección ip al nombre (o viceversa) y en caso de no encontrar dicho dato, se comunica con otro DNS asociado que tiene registrado en la base de datos que puede llegar a tener dicho sitio y así sucesivamente hasta que lograr crear la relación. Existen numerosas herramientas que facilitan la creación de éstos servidores, pero hay una especialmente conocida: bind9.


En este caso voy a realizar un pequeño DNS casero, pero perfectamente funcional con bind9. Para ello simplemente haría falta un sistema basado en Debian; en mi caso en particular he realizado las pruebas con Debian8, resultando exitosas, pero al menos en Ubuntu y en Elementary OS debería de funcionar también.

Primero es importante asegurarse de que el servidor en cuestión está configurado con una ip estática; Esto es debido a que en caso de que la ip otorgada por el servidor DHCP cambie, el DNS podría dejar de funcionar correctamente. La consulta es tan sencilla cómo realizar un cat /etc/network/interfaces. os podeis encontrar con dos opciones:

1.Esté configurado el sistema con ip dinámica; lo cual mostraría algo cómo esto:


2.Esté configurado con ip estática, que variaría dependiendo del entorno. Aún así, este sería un ejemplo de configuración de ip estática.


Ahora que tenemos el entorno adecuadamente preparado, falta instalar la herramienta, ya que ésta no está incluida por defecto en el sistema operativo. Por suerte se trata de un software que va incluido en los repositorios, con lo que tan sólo habría que escribir apt-get install bind9.

Tras instalar el software, habría que pasar a su configuración, pues por defecto bind9 no hace nada. Para ello es necesario crear y configurar una serie de ficheros, los cuales están almacenados en /etc/bind/. La configuración estaría basada en dos pasos: La resolución de dominio directa y la resolución de directo inversa.


Resolución directa


La resolución directa se basaría en que a la hora de apuntar al nombre de dominio del servidor, se sea capaz de reconocer su dirección ip equivalente; es decir que si por ejemplo se le hiciese ping al nombre de dominio, se supiese a que dirección ip corresponde. Para ello habría que configurar 2 ficheros, que se encuentran almacenados en el directorio /etc/bind/.


Comenzamos con el fichero más importante de bind: el fichero named.conf.local. Este almacena los datos generales del servidor DNS y por defecto sólo posee unas pocas líneas de comentarios. En dicho fichero habría que añadir lo siguiente:

  1. zone "nombre_dominio" {
  2.         type master;
  3.         file "/etc/bind/db.nombre_dominio_sin_.net";
  4. };

Esta sería la estructura general que habría que añadir y el nombre sería aquel que uno desee. Por ejemplo, en mi caso particular he optado por el dominio pruebaivan.net con lo que si nos basamos en la estructura mencionada arriba quedaría así:


Esto sería lo sencillo. Ahora habría que configurar el fichero db.nombre_domino (en mi caso db.pruebaivan), el cual. cómo habréis podido observar, no existe en la carpeta bind. Aún así eso no significa que haya que crearlo desde cero. Se puede usar el fichero db.local cómo plantilla, con lo bastaría con copiar dicho fichero y renombrar la copia con el nombre de dominio mediante el comando: cp db.local db.pruebaivan. Si entramos en el fichero que acabamos de generar veremos que posee muy poca información y que la poca que hay hace referencia a la dirección 127.0.0.1. Habría que modificar su contenido para que quede con la siguiente estructura a esto:

IMPORTANTE: Revisar muy atentamente la puntuación. Cómo podéis ver al final del nombre de dominio siempre va un . sin el cual no os va a funcionar correctamente.

  1. $TTL    604800
  2. @       IN      SOA     nombre_dominio. root.nombre_dominio(
  3.                                 2       ; Serial
  4.                            404800       ; Refresh
  5.                             86400       ; Retry
  6.                           2419200       ; Expire
  7.                            604800 )     ; Negative Cache TTL
  8. @       IN      NS      nombredominio.
  9. @       IN      A       ip_servidor
  10. @       IN      MX 0    nombre_dominio.
  11. www     IN      A       ip_servidor
  12. uah     IN      CNAME   nombre_dominio.

Las 7 primeras líneas no haría falta ponerlas, ya que vienen incluidas por defecto, pero las he puesto para tener toda la información lo más detallada posible. Dichas primeras líneas consisten en los parámetros por defecto a la hora de resolver el nombre del dominio, parámetros que en un principio no son necesarios modificar ya que de por sí están bien. Con la siguiente estructura habría que modificar las líneas para adaptarlas a nuestro caso en particular. En mi caso particular la ip del servidor es 192.168.1.10 y el nombre de dominio pruebaivan.net; con lo que quedaría así:



Con esto configurado ya estaría bind preparado para realizar la resolución, solo habría que reiniciar el servicio mediante /etc/init.d/bind9 restart; pero ahora mismo la dirección DNS de nuestro servidor no está apuntándose a sí mismo con lo que habría que modificar el fichero /etc/resolv.conf, borrar todo su contenido y escribir lo siguiente:

nameserver 127.0.0.1 (En Debian)
dns-nameserver 127.0.0.1 (En Ubuntu)


Probando la resolución directa

Ahora quedaría realizar la prueba. Existen dos formas de probar. La primera es desde el propio servidor dns mediante el comando: host nombre_dominio. En caso de tener todo correctamente configurado, debería de mostraros su dirección ip equivalente, tal que así:


Otra alternativa es probar mediante el comando ping. Dicha prueba se puede hacer desde el propio servidor, o desde un equipo dentro de la misma red y que esté apuntando al recién creado DNS. Haré la prueba desde un equipo con Windows, ya que antes he mostrado cómo cambiar el DNS en Linux.

Para realizar el cambio en Windows (en este caso en Windows 7) tendríamos que dirigirnos al Panel de control y en la sección de Redes e Internet, clickar en Ver el estado y las tareas de red. Dentro de dicha sección, habría que entrar en Conexión de are local.


Una vez dentro, habría que clickar en el botón Propiedades y acceder a la sección Protocolo de Internet versión 4 (TCP/IPv4). En la zona inferior, observareis dos opciones: Una de ellas es Usar las siguientes direcciones de servidor DNS; seleccionaríamos dicha opción y en la casilla al lado de Servidor DNS preferido, pondríamos la dirección ip del servidor DNS, en mi caso 192.168.1.10.

Ahora sólo habría que pulsar la tecla windows + r y escribir cmd, para mostrarnos la consola. En este caso Windows y Linux comparten la misma sintaxis: ping nombre_dominio.


En caso de recibir respuesta, significaría que el servidor está correctamente configurado; en caso contrario habría que revisar de nuevo la configuración y repetir las pruebas hasta obtener el resultado adecuado.


Resolución inversa


Ahora sería el turno de configurar el DNS para la resolución inversa; es decir hacer que se asocie la ip del servidor DNS al nombre de dominio.  Para ello habría que dirigirse a la misma carpeta que antes, es decir, /etc/bind, y entrar de nuevo en el fichero de configuración general: named.conf.local. Manteniendo lo que ya habíamos escrito antes, añadimos el siguiente contenido:


  1. zone "prímeros octetos de la ip del servidor al revés (pueden ser 3 o 2 dependiendo de la máscara de red).in-addr.arpa" {
  2.         type master;
  3.         file "/etc/bind/db.primer_octeto";
  4. };

Alguno puede estar confuso ante lo escrito en la prímera y tercera línea. Para poneros en situación pondré cómo ejemplo mi ip: 192.168.1.10, con máscara 255.255.255.0; Aquí se necesitan unas nociones básicas de redes ipv4, pero por ejemplo, la mayoría de los hogares poseen el direccionamiento ip 192.168.1.X, teniendo cómo puerta de enlace la ip 192.168.1.1. Eso quiere decir que un equipo siempre va a tener una ip entre 192.168.1.2 y 192.168.1.254 (la 255 no se usa porque se trata de la dirección de broadcast). Con lo que cualquier ip dentro de la red SIEMPRE va a empezar con la dirección 192.168.1. y eso escrito al revés sería 1.168.192; así que en la primera línea sería:  zone "1.168.192.in-addr.arpa". Con respecto a la tecera línea; una ipv4 está compuesta por 4 octetos separados por . con lo que cómo en este caso tenemos una ip 192.168.1.X, el primer octeto sería 192. Basándonos en estos conceptos. este sería mi fichero de configuración final, completo:


Ahora haría falta configurar el fichero que hemos puesto en file, en este caso en particular db.192, que cómo habréis podido observar, no existe. Al igual que con la resolución directa, existe un fichero de configuración parecido que podemos usar cómo plantilla. Se trata del fichero db.127; con lo que al igual que antes habría que hacer cp db.127 db.192. Dicho fichero tiene una estructura bastante simple:

  1. $TTL    604800
  2. @       IN      SOA     nombre_dominio. root.nombre_dominio(
  3.                                 2       ; Serial
  4.                            404800       ; Refresh
  5.                             86400       ; Retry
  6.                           2419200       ; Expire
  7.                            604800 )     ; Negative Cache TTL
  8. @       IN      NS      nombredominio.
  9. 1       IN      PTR     nombredominio.
  10. 2       IN      PTR     nombredominio.
  11. ...

Los ... representa que se pueden añadir tantas líneas cómo direcciones ip que queremos añadir. Esos números que aparecen en la primera columna representan al último octeto de la ip, es decir: 192.168.1.1, 192.168.1.2, etc... Esas ips serán las que podrán asociar la ip del servidor a su nombre de dominio; En caso de que una ip, no se encuentre en la lista, no será capaz de realizar dicha asociación. En este caso yo por ejemplo he puesto de 1 al 10, pero puede ser perfectamente de 1 a 254, aunque si que es recomendable poner siempre en la lista la el último octeto perteneciente al servidor DNS (en mi caso el 10) para evitar cualquier posible complicación. Este sería mi fichero de configuración:


Con estos cambios hechos sólo habría que reiniciar de nuevo bind mediante /etc/init.d/bind9 restart

Probando la resolución inversa

Aquí también se puede probar de dos formas. La primera es desde el propio servidor dns. Sólo habría que escribir el comando host ip_servidor. Si se tiene todo correctamente configurado, y nos hemos asegurado de introducir la ip del servidor DNS en la lista de direcciones del fichero db.192, tendríamos que recibir el siguiente mensaje de respuesta:


La otra forma de probarlo sería desde otro equipo. Siguiendo la misma dinámica, voy a hacerlo desde un equipo con Windows 7. Habría que volver a configurar dicho equipo de nuevo tal y cómo he explicado en Probando la resolución directa, y entrar en la consola. En este caso no vamos a usar el comando ping, pues si hacemos ping a la dirección ip del servidor DNS nos va a devolver la respuesta sin más. En este caso vamos a usar el comando nslookup ip_servidor. Obviamente, el equipo que vamos a usar para la prueba, tiene que tener una ip que esté contemplada en el listado de db.192, pues sino no la prueba no funcionará. Si poseemos todo bien configurado y con una ip que se encuentre dentro de dicha lista, deberíamos recibir la siguiente respuesta:


Con esto ya tendríamos un pequeño pero funcional servidor DNS casero. Espero que os haya sido útil.

Saludos.