Información blog

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

jueves, 22 de diciembre de 2016

Cómo proteger el servidor DNS en Linux con DNSSEC

Hace ya tiempo hablé sobre cómo construir nuestro propio servidor DNS con bind9; un servidor que si bien era sencillo era funcional; la cuestión está en que hoy en día no basta con que un servicio funcione; también tiene que ser seguro. La seguridad es un tema que es, desgraciadamente, poco valorado en mucho ámbitos... Sí, uno se preocupa de la seguridad, pero no aplica ninguna medida, con lo que dicha "preocupación" suele ser ficticia. La cuestión es que este servicio en concreto, el DNS, es de importancia vital hoy en día y la seguridad de éste no debe de ser tomada a la ligera si no queremos sufrir sustos indeseados tales como la toma del control de este servicio para que le dirija a uno a una web fraudulenta en vez de a la original. Afortunadamente, Linux posee un recurso muy útil que, por un lado no supone ninguna molestia para el usuario final, y que por otro lado proporciona una sólida capa de seguridad para este servicio. Dicho recurso se llama DNSSEC.

DNSSEC_Portada

DNSSEC es una extensión de seguridad que se encarga de "firmar" digitalmente las transmisión de datos de forma que certifica que el sitio es válido y que no ha sido suplantado. Con esto tratamos de tener la seguridad de que realmente estamos visitando el sitio que deseamos. Es importante tener en cuenta que esta tecnología no sustituye al cifrado SSL; es decir que cada tecnología tiene su propósito. SSL, cifra las conexiones mientras que DNSSEC verifica la autenticidad del nombre de minio. Una de las virtudes de extensión de seguridad es que está incluida por defecto en el sistema, con lo que no requiere que se descarguen paquetes adicionales para hacer funcionar esta extensión, si bien obviamente habría que realizar una serie de configuraciones para que dicha extensión esté activa y que funcione correctamente; configuraciones que veremos a continuación.

Antes de nada, doy por supuesto que ya se ha creado el servidor DNS, con lo que se dará por sentado que ya se han aplicado las configuraciones mínimas para tener un DNS funcional. En caso contrario recomiendo mirar el artículo de creación de un DNS con bind9, cuyo link se encuentra al principio de este post. Comencemos entonces.

Lo primero que necesitamos hacer es habilitar el uso de la extensión DNSSEC dentro de nuestro servidor DNS; cosa que sería tan sencilla como acceder al fichero /etc/bind/named.conf.options y editarlo. Veréis que dentro de dicho fichero, todo el contenido se encuentra dentro de una sección entre {} llamada "options". En dicha sección habría añadir las siguientes líneas:

  1. dnssec-enable yes;
  2. dnssec-validation yes;
  3. dnssec-lookaside auto;

En caso de encontrarnos con líneas parecidas a éstas dentro de dicho fichero, habría que o bien comentar dichas líneas o eliminarlas. Ahora bien, no pensemos que con ésto seria suficiente para fortificar nuestro DNS; hace falta crear una serie de "claves" que serán las que se usarán para más adelante realizar la verificación de que efectivamente el nombre del dominio al que estamos accediendo, es real. Todo el proceso se realizará suponiendo que el nombre del dominio es pruebaivan.net, con lo que cualquier aplicación que se quiera hacer para otro nombre, tendrá que realizarse modificando dicho nombre. Habría que crear dos pares de claves (al decir dos pares de claves me refiero a que habría que crear dos claves públicas y privadas). Para dicha creación nos tendríamos que situar dentro del directorio /var/cache/bind/ y teclear el siguiente comando:

dnssec-keygen -a NSEC3RSASHA1 -b 4092 -n ZONE pruebaivan.net

Este proceso tardará bastante tiempo, pues nos estará creado una clave pública y privada de un tamaño de 4092 bytes usando un cifrado "NSECRSASHA1". A modo de recomendación, sería deseable abrir una terminal aparte y hacer que la CPU del equipo esté trabajando con el fin de que el proceso de creación de claves sea más rápido, ya que éste suele ser bastante lento. Yo generalmente, al crear un clave, abro una terminal aparte y escribo el siguiente comando:

i=1while [ $i > 0 ]do echo $ii=$(($i + 1));done

Tras finalizar el proceso que, dependiendo de la potencia de nuestro equipo, puede tardar desde minutos hasta horas, habría que crear otro par de claves más; par de claves que también estarían en la misma carpeta, es decir en /var/cache/bind. El comando para crear dicho nuevo par de claves, difiere bastante poco del anterior, tal y como vereis a continuación:

dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4092 -n ZONE pruebaivan.net

Ahora vamos a crear un fichero de "zonas" que, por un lado incluya la configuración referente al hostname, y que por otro lado tenga en su interior referencias a las claves que acabamos de crear; en concreto a las claves públicas que acabamos de crear cuya extensión sea .key. El fichero en cuestión  se llamará nombre_dominio.zone y estará ubicado en el mismo directorio que las claves que hemos creado; mi caso el dominio se llamaría pruebaivan.net.zone. En dicho fichero habría que volarle primero desde la consola las siguientes líneas; en vuestro caso, tendríais que sustituir "pruebaivan.net "por vuestro nombre de dominio:

echo \$TTL 3600 > ; for key in `ls Kpruebaivan.net*.key`do echo "\$INCLUDE $key" >> pruebaivan.net.zone; done

Con este volcado en el fichero, el aspecto de éste tendría que ser algo medianamente parecido a lo siguiente:

  1. $TTL 3600
  2. $INCLUDE Kpruebaivan.net.+007+45422.key
  3. $INCLUDE Kpruebaivan.net.+007+63606.key

Pero con esto de por sí no es suficiente; tenemos que añadir una serie de configuraciones extra para que el fichero sea válido; en concreto el fichero final sería el siguiente, donde pruebaivan.net sería el nombre de dominio y 192.168.1.6 sería la IP de dominio:

  1. $TTL 3600
  2. $INCLUDE Kpruebaivan.net.+007+45422.key
  3. $INCLUDE Kpruebaivan.net.+007+63606.key
  4. @       IN      SOA     pruebaivan.net. root.pruebaivan.net. (
  5.                               2         ; Serial
  6.                          604800         ; Refresh
  7.                           86400         ; Retry
  8.                         2419200         ; Expire
  9.                          604800 )       ; Negative Cache TTL
  10. ;
  11. @       IN      NS      pruebaivan.net.
  12. @       IN      A       192.168.1.6
  13. @       IN      MX 0    pruebaivan.net.
  14. www     IN      A       192.168.1.6
  15. uah     IN      CNAME   pruebaivan.net.

Ya casi estaría, ahora habría "firmar" este fichero de zonas mediante el comando dnssec-signzone para que las zonas que aparecen en éste se consideren "seguras", Esto se logra mediante el comando de a continuación:

dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -o pruebaivan.net -t pruebaivan.net.zone

Este proceso de firma crearía un fichero de zonas firmado llamado nombre_dominio.zone.signed que sería el fichero de zonas firmado mediante nuestro último comando... Ahora obviamente habría que usarlo, pues en caso contrario el proceso realizado hasta ahora no habría valido para nada. Esto es tan sencillo como editar el fichero /etc/bind/named.conf.local y cambiar la ruta del parámetro file de la zona por la ruta del nuevo fichero de zonas... Véase el siguiente ejemplo para tener una idea más clara:

Antes:

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

Despues:

  1. zone "pruebaivan.net" {
  2.         type master;
  3.         file "/var/cache/bind/pruebaivan.net.zone.signed";
  4. };

Ahora únicamente habría que reiniciar el servidor DNS para aplicar los cambios, que sería tan sencillo como escribir:

/etc/init.d/bind9 restart

Ahora bien. ¿Cómo podemos saber si efectivamente nuestro host está usando esta extensión? A nivel de usuario final no notaremos nada, pero si "sondeamos" el host mediante el comando dig, veremos que efectivamente estamos usando dicha extensión de seguridad y que efectivamente, el hostname es el que debe ser:

dig DNSKEY pruebaivan.net. +multiline

dig_resultado

Como veis, si bien el proceso de añadir la capa de seguridad de DNSSEC es algo tedioso, se trata de una medida de seguridad que muy interesante que podemos usar en combinación con otras medidas tales como el cifrado SSL o el uso de cortafuegos.

Espero que os haya resultado útil.

Saludos.

miércoles, 14 de diciembre de 2016

Cómo personalizar la apariencia de GRUB2

En el día de hoy quiero traeros algo que si bien no se puede considerar como algo "útil" o "práctico", sin duda puede ser calificado como interesante; especialmente para aquellos amantes de la personalización de sus entornos GNU Linux. A muchos les gusta darle un toque único a su escritorio con el fin de que sea todo un espectáculo a nivel visual; cosa que está muy bien, pero que puede llevarse un paso más allá personalizando la apariencia de GRUB2.

GRUB2_Portada

Está personalización es bastante sencilla, más aún cuando se está familiarizado con algunos aspectos del GRUB2, pero sí que conviene tener algunos puntos claros para evitar andar realizando configuraciones a base de "prueba y error".  El primero de todos, sería tener claro donde y cómo realizar la configuración en cuestión... Aquí dependiendo del sistema operativo que se esté usando, el fichero de configuración puede variar, pero lo mejor sería crear uno personalizado que, hasta el momento, jamás me ha dado problemas, al menos en Debian y en Ubuntu. El fichero de configuración se llamaría custom.cfg y lo crearíamos como root dentro del directorio /boot/grub.

En este fichero podríamos añadir cualquiera de los siguientes cuatro parámetros:
  • set color_nomal: Este parámetro especificaría el color de las letras que se encuentran fuera del menú de opciones del GRUB2. Es decir que colorearía el título y el texto que rodea el recuadro de selección de sistema operativo.
  • set color_highlight: Este parámetro especifica el color de las letras que se encuentren resaltadas debido a que han sido seleccionadas. Este parámetro no incluye la opción seleccionada dentro del menú de selección de sistema operativo.
  • set menu_color_nomal: Aquí seleccionaríamos los colores del texto del menú de selección de sistema operativo. Estos colores únicamente afectarían a las líneas no seleccionadas del menú.
  • set menu_color_highlight: Está opción sería la inversa a la anterior, es decir que afectaría únicamente al elemento seleccionado en el menú.

Obviamente tendríamos que saber qué valores asignar a estos parámetros; valores que son realmente simples, pues siempre tendrán la misma estructura: Parámetro=fgcolor/bgcolor. Fgcolor haría referencia al "foreground color", es decir al color de las letras, mientras que bgcolor haría referencia al "background" color que sería el color que aparecería detrás de las letras. Ahora la pregunta sería muy obvia: ¿Qué colores podemos usar? Obviamente no podemos usar cualquier color, sino uno de los que GRUB2 nos permite introducir. Los colores disponibles serían:

colores_GRUB2

Aquí habría que hacer un pequeño inciso, que sería que el color negro (black) es especial, ya que especificamos dicho color como bgcolor (background color), éste sería transparente y no negro. Siguiendo estas indicaciones, podríamos rellenar el fichero custom.cfg tal que así:

  1. set menu_color_highlight=green/black
  2. set menu_color_normal=blue/black
  3. set color_normal=cyan/black

Con esta configuración guardada únicamente habría que actualizar la configuración del GRUB2, lo que sería tan sencillo como escribir el comando:

update-grub

Con este cambio y reiniciando el sistema, lograríamos cambiar los colores de los diferentes elementos del GRUB2, exceptuando del fondo de pantalla que se mantendría igual, tal y como podemos ver a continuación.

grub_color

Si esto no nos bastase y quisiéramos también personalizar el fondo de pantalla del gestor de arranque, podemos hacerlo de dos formas. La primera sería usando una imagen a nuestro gusto que cumpliese los siguientes requisitos, que, si bien pueden parecer sencillos, hay que tenerlos presentes:

  • Tienen que estar en formato JPG,PNG o TGA.
  • Tienen que ser de 8 bits (256 colores).
  • La imagen tiene que ser RGB.

La mejor forma de asegurarnos de ello sería usando la herramienta GIMP, ya que nos da la libertad suficiente sobre las imágenes como para controlar estos puntos. Si en cambio preferimos optar por la alternativa más cómoda, podemos instalarnos el paquete grub2-splashimages, que nos descarga una serie de imágenes TGA que cumplen todos los requisitos, aunque obviamente esta "galería" sería limitada y no tiene que tener imágenes que sean 100% de nuestro gusto. Al ser un paquete integrado en los repositorios oficiales podemos hacer:

apt-get install grub2-splashimages

A sabiendas de la imagen que queremos usar, pasaríamos a personalizar el fondo de GRUB2, para lo cual habría que editar el fichero /etc/default/grub y añadirle una línea con la estructura:

GRUB_BACKGROUND="ruta_imagen"

En mi caso por ejemplo sería:

GRUB_BACKGROUND="/home/ivan/tux_bytelearning.png"

Con esta línea añadida guardaríamos los cambios y, una vez más, los aplicaríamos mediante el comando update-grub, de nuevo. Ahora únicamente tendríamos que reiniciar el sistema y podríamos disponer de un gestor de arranque completamente personalizado como el de a continuación:

GRUB2_Personalizado

Como veis, la personalización del GRUB2 no es especialmente complicada. Simplemente requiere de manejar unos pocos pequeños y de algo de tiempo en caso de querer poner un fondo completamente personalizado, lo cual con herramientas como GIMP no es especialmente complicado aún sin conocimientos sobre esta herramienta.

Espero que os haya resultado útil.

Saludos.

domingo, 4 de diciembre de 2016

Drivers; una asunto ventajoso y desventajoso al mismo tiempo en Linux

Hoy quiero hablaros sobre uno de los temas más... polémicos dentro del mundo de GNU Linux; los drivers. Generalmente, cuando hablamos de las ventajas y desventajas que tienen los sistemas Windows y Linux, podemos hablar de las libertades ofrecidas del software libre, de la flexibilidad que ofrecen los sistemas GNU Linux, o la diferencia entre la curva de aprendizaje que uno padece con Windows y con Linux... Y también un tema bastante sonado en su día, que ahora lo es menos, es la compatibilidad de los drivers; pues generalmente es más probable que un sistema Windows tenga más posibilidades de ser compatible que Linux... O al menos esa es la creencia popular.


Lo cierto es que las quejas acerca de los drivers en Linux siempre ha sido un tema bastante recurrente; tema que afortunadamente ha ido mejorando notablemente con el paso del tiempo, y que salvo exceptuando algunos casos concretos, como podrían ser los drivers de NVIDIA, ya no son un problema tan grande como solían ser en su día... ¿Pero eso a qué se debe? ¿Es decir, por qué esa diferencia que había por aquel entonces es menor ahora?

Lo cierto es que esta mejora no sería real en la actualidad sin la ayuda de todos los contribuyentes al Kernel de Linux y la gestión de las mejoras de éste realizadas por Linus Torvalds. Este kernel, usado en una gran número de sistemas, contiene un enorme número de funcionalidades que posibilitan la comunicación entre el hardware y el software, y obviamente, entre estas funcionalidades están incluidos dichos drivers...

Esto es algo bastante curioso porque es algo que únicamente pasa con este tipo de funcionamiento, ya que en Windows, por ejemplo la situación es completamente opuesta. Me explico: Cualquier periférico que se fabrique, tiene que ser fabricado para que sea compatible con Windows; y no solo con Windows en sí, sino con las diferentes versiones de éste (XP, 7,8, 10); el fabricante de dicho periférico tiene que tomarse la molestia en realizar toda la tarea, y no solo eso sino que tiene que preocuparse en que sea operativo en todas las versiones de Windows existentes.

En el Kernel de Linux la actitud es generalmente lo contrario, pues son los contribuyentes del Kenel los que tienen que adaptar el producto a dicho Kernel... Afortunadamente los fabricantes han  ido adoptando una actitud mucho más contributiva, en la que aportan su ayuda al kernel, ya sea dándoles el driver adaptado para el kernel, o al menos otorgándoles la información suficiente para que los programadores puedan crear su propio driver de tal forma en que el periférico pueda integrarse en los sistemas que contengan dicho Kernel instalado.

¿Esto es una método más o menos eficiente? La respuesta más sincera sería... Depende. El hecho de que el fabricante haga todo el trabajo de integración de drivers por ti, es algo increíblemente cómodo, pues en caso de que luego el periférico no fuese compatible, sería su problema y no un problema del Kernel o del sistema operativo. Pero esa ventaja representa al mismo tiempo una desventaja, ya que si por algún casual el fabricante no integrase su producto para un entorno en concreto, ya sea por la obsolescencia del producto por falta de recursos, el usuario final se quedaría en la estacada, haciendo que esa persona, que ha desembolsado una cantidad determinada para comprar dicho producto, se quede en la estacada; y esto, se mire de por donde se mire, es un gran problema de cara al usuario final.

Os pongo sobre una situación real que he visto recientemente. Una persona de mi entorno, compró hace varios días un periférico antiguo que necesitaba para poder comunicar su ordenador, con Windows 10, con un dispositivo que, obviamente, también era antiguo (si bien este funcionaba correctamente). Imaginaros su sorpresa al conectar el equipo y ver que no lo reconocía, y que peor aún; que los drivers que había publicado el fabricante eran válidos únicamente hasta Windows 7... En cambio al conectarlo a mi portátil con Linux, sí. ¿Por qué?

Esto es debido en buena parte a la filosofía tomada por el kernel de Linux; y es que si un driver es añadido a una versión de Kernel, todas las versiones posteriores lo incluyen, y generalmente no es eliminado dicho driver hasta muchísimos años después, cuando el periférico no es solo obsoleto, sino que no es usado por absolutamente nadie... Con lo que generalmente, a excepción de los drivers más nuevos podemos tener la certeza de que nuestros sistemas Linux van a ser 100% compatibles con nuestros periféricos, independientemente de los años que éstos lleven el mercado e independientemente del tipo de sistema operativo que se éste usando, siempre y cuando dicho sistema operativo tenga una versión de kernel compatible...

Con esto no quiero hablar a favor ni de la forma de trabajar uno ni del otro, pero indudablemente cada forma de trabajar es curiosa y en mi opinión son evidentes tanto las ventajas como las desventajas.

En conclusión podríamos decir que si bien Windows sigue estando por encima de Linux en términos de adaptabilidad de los periféricos más recientes; la filosofía de Linux ayuda a que una vez estos drivers han sido añadidos al núcleo, éstos perduren en el paso del tiempo, siendo un gran punto a favor de estos sistemas.

Espero que os haya resultado interesnate.

Saludos.