Información blog

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

viernes, 20 de enero de 2017

Ataque de transferencia de zona DNS en Linux

En anteriores ocasiones ya he hablado sobre la importancia del DNS (Domain Name Service), y su configuración, pues se tratan de un servicio de una enorme relevancia que hace que Internet sea lo que hoy en día todos conocemos; basta con escribir un nombre de dominio para poder acceder a una web; evitándonos tener que memorizar las IPs de los sitios. Hoy quiero hablaros de una configuración especifica que tienen estos servidores; una configuración que puede convertirse en un arma de doble filo si no tenemos cuidado: Se trata de la transferencia de zona.

DNS_Portada

Lo más común en los entornos empresariales y/o pensados para dar servicio a un gran número de personas, es que los servidores DNS estén compuestos por varios equipos físicos: Un maestro y varios esclavos que estarían para ayudar a distribuir el tráfico y para que en caso de que el maestro se cayese, no nos quedásemos tirados. Para que no haya problemas con la información, cuando un DNS secundario es arrancado para convertirse en el DNS principal se realiza una transferencia de zona; transferencia que replicaría la "base de datos" del DNS y que, para bien o para mal, está activada por defecto. Veamos un sencillo ejemplo basado en el archivo de configuración named.conf.local de bind9.

  1. zone "pruebaivan2.net" {
  2.         type master;
  3.           file "/etc/bind/db.pruebaivan2";
  4. };
  5. zone "1.168.192.in-addr.arpa" {
  6.         type master;
  7.         file "/etc/bind/db.192";
  8. };

Esta configuración es una muy típica en los servidores DNS, con la diferencia de que obviamente las IPs serán distintas; pero lo importante no son los datos sino el concepto en sí. Si os fijáis bien, no hay ningún parámetro que haga referencia a la transferencia de zona; dicho concepto ya está por defecto activado. Esto está pensado para que así no haya restricción alguna para realizar la transferencia y que no haya ningún impedimento a la hora de pasar la información desde el servidor primario a algún secundario. El problema está en que dicha transferencia es abierta; es decir que se puede realizar la transferencia a cualquier destino; y he ahí el problema.

Todo sistema informático, tan pronto como está expuesto al público, es susceptible de ser hackeado; y el DNS, obviamente, no es una excepción; más aún cuando éste servicio es de vital importancia para evitar tener que memorizar direcciones IP.

Para hacer la prueba usaremos un comando muy conocido pero que cuyo uso no es tan extendido como otros comandos de red, tales como traceroute o nmap. Sería el comando dig, cuyo proposito es recavar información sobre un host en concreto o, en este caso, recabar y transferir dicha información. Hay que recalcar que dig en sí no es una herramienta con fines malignos; la cuestión está que toda herramienta puede tener diferentes usos dependiendo de quien la use.

Para realizar una transferencia de zona usaríamos la siguiente estructura del comando dig:

dig @host_origen axfr host_destino

El comando en sí haría lo siguiente: Mediante el @host_origen, haríamos referencia al DNS al que queremos realizar la transferencia de zona; el parámetro axfr especifica que la acción que se quiere realizar es la transferencia de zona; mientras que el host_destino sería el DNS al que queremos realizar la transferencia. Por ejemplo:

dig @pruebaivan2.net axfr pruebaivan2.net

Lo más impactante es que ni siquiera es necesario tener otro host propio; el propio host suyo puede darnos la información al realizar la transferencia de zona, ya que lo que estamos haciendo al realizar dicha transferencia sería actualizar y sincronizar los datos DNS existentes. Mirad este pequeño ejemplo:

lista_dns

Como podéis ver estaríamos viendo el contenido de la base de datos, cosa muy peligrosa ya que vemos qué información maneja, y la información es poder...

Afortunadamente tenemos una solución a dicho problema; una solución muy simple que no conlleva apenas esfuerzo por nuestra parte. Limitar la transferencia de zona para que haga las transferencias a unas IPs en concreto; IPs que nosotros conozcamos y que sepamos que son de "confianza". Para aquello editaremos el fichero named.conf.local y usaremos el parámetro allow-transfer. Dicho parámetro especificará qué IPs en concreto queremos que puedan realizar la acción de transferencia; cualquiera que lance la petición de transferencia que no tenga una de las IPs mostradas en dicho parámetro, simplemente no tendrá éxito.

  1. zone "pruebaivan2.net" {
  2.         type master;
  3.           file "/etc/bind/db.pruebaivan2";
  4.           allow-transfer {192.168.1.7; localhost; };
  5. };
  6. zone "1.168.192.in-addr.arpa" {
  7.         type master;
  8.         file "/etc/bind/db.192";
  9.         allow-transfer {192.168.1.7; localhost; };
  10. };

Obviamente, para aplicar los cambios habría que reiniciar el servidor DNS; es decir:

/etc/init.d/bind9 restart

Por último, para comprobar si en efecto la transferencia de zona está "capada"; tendríamos que, por un lado, ejecutar el comando dig a nivel local para ver que efectivamente todavía funciona la transferencia; y por otro lado ejecutar edig desde una IP no autorizada. En caso de realizar la petición de transferencia desde una IP inadecuada obtendríamos un mensaje de respuesta tal como el siguiente:

dnstransfer_fail

Como veis, una configuración descuida del servidor DNS puede resultar fatal, ya que podríamos estar dejando "abiertos" varios parámetros que por defecto están pensados para darnos flexibilidad, pero que pueden ser aprovechados por personas malintencionadas para obtener información de nuestros servicios.

Espero que os haya resultado útil.

Saludos.

miércoles, 11 de enero de 2017

Permisos especiales en Linux: Sticky bit, SUID y SGID

Hoy quiero traeros un concepto que si bien no es especialmente "desconocido" hay muchas personas que lo pasan por alto debido a su poco uso. En su día hablé sobre el concepto de los permisos de los ficheros en Linux con bastante profundidad; pero hoy quiero traeros un concepto derivado de éste que va un pequeño paso más allá: Los permisos especiales.

Permisos_especiales_portada

Estos permisos están diseñados tanto para garantizar un cierta "flexibilidad" a la hora de ejecutar algunos binarios cómo para evitar posibles accidentes por parte de algunos usuarios... Permisos especiales que, si bien son pocos, conviene conocer adecuadamente. En concreto habrían 3 tipos de permisos especiales.


Sticky bit

Por un lado tendríamos el sticky bit; que se trata de un permiso especial que puede ser asignado tanto a ficheros como directorios. Este permiso puede ser muy útil en ficheros de cierta relevancia tales como los ficheros de log o ficheros importantes, ya que lo que permite es leer y escribir en el fichero y/o directorio en cuestión, pero no se podría ni renombrar ni borrar por nadie a excepción de dos usuarios: El creador de éste y root; lo que hace que a nivel de seguridad tengamos una cierta tranquilidad, ya que los usuarios pueden leer y escribir en el fichero con libertad pero jamás podrán alterar su nombre ni borrarlo. Este permiso se puede agregar de dos formas; a nivel directo o a nivel octal.

La forma directa sería:

Para añadir el permiso sticky bit:
chmod +t fichero

Para quitar el permiso sticky bit:
chmod -t fichero

A nivel octal lo veremos mejor más adelante con el fin de englobar todos los permisos especiales.


SUID

Por otro lado tendríamos el SUID o "Set Owner ID up on execution", cuya función sería que el usuario que ejecute el archivo, tendría exactamente los mismos permisos que el dueño de éste. Esto puede parecer algo simple pero no lo es; si por ejemplo tuviésemos un archivo con permisos de ejecución (para todos) y tuviese dicho SUID, cualquiera que lo ejecute lo estaría ejecutando como si fuese el dueño del script, lo que es muy útil y muy peligroso al mismo tiempo. Imaginemos que el script perteneciese a root y tuviese permisos de ejecución para todos y el SUID activado; además el contenido de dicho script , escrito en C y llamado test.c, sería algo como lo siguiente:

  1. #include <stdio.h>
  2. #include <unistd.h>
  3. main(){
  4.   printf("UID: %d, EUID: %d\n",getuid(),geteuid());
  5.   system("cat /etc/shadow");
  6. }

Obviamente el programa estaría compilado; es decir:

gcc test.c -o test

Al ejecutar lo que pasaría sería que mostraría los valores UID y EUID e intentaría ejecutar el comando "cat /etc/shadow". UID sería el User ID del usuario que generalmente sería valor a partir de 1000 (1000, 1001, 1002...) y el EUID sería el Effective User ID, valor que indica el User ID que se está usando para realizar la tarea en cuestión. Al no tener el permiso especial activo, ambos valores serían iguales y el comando cat diría que no tenemos permisos para ver el contenido del fichero. Ahora bien, vamos a activar el SUID:

chmod u+s test

Si lo ejecutásemos veríamos por un lado que el valor EUID ha cambiado a 0 (ya que el UID de root es ese) y que permite ejecutar el comando cat sobre el fichero shadow, lo cual es peligroso.

Esto implica que si bien este permiso es útil, hay que ser extremadamente peligroso con él ya que se puede utilizar como recurso para escalar privilegios. La forma de deshabilitar este permiso sería:

chmod u-s test


SGID

Es extremadamente parecido al SUID con la diferencia de que en este caso el SGID o "Set Group ID on execution" tomaría los permisos del grupo, no del usuario en sí. Aún así, si el grupo fuese root o uno grupo con privilegios de administrador, este permiso podría ser usado en favor de la escalada de privilegios.

Para añadir el SGID habría que escribir:
chmod g+s fichero

Mientras que para quitarlo sería:
chmod g-s fichero


Cambiando los permisos especiales a nivel Octal

En mi opinión, el conocer como cambiar los permisos especiales a nivel octal es mucho más útil que a nivel "normal" ya que ofrece muchas más potencia y flexibilidad el hacerlo de esta forma; no es obligatorio hacerlo así; es más es perfectamente viable hacer el cambio de permisos de las formas que he comentado, pero en mi opinión es muy útil conocer la forma de cambiar los permisos en octal.

Lo primero que habría que saber sería que cuando hacemos una asignación de permisos "normales" a nivel octal, lo hacemos mediante el comando chmod más tres dígitos que pueden oscilar entre 0 y 7; pues bien, el octal que asignaría los permisos especiales iría antes de dichos tres dígitos, haciendo que el comando chmod se tenga que hacer mediante el comando chmod más 4 dígitos. Por ejemplo:

chmod 1755 fichero

El 1 sería el octal que haría referencia a los permisos especiales y sería dicho octal el que habría que tener en cuenta a la hora de asignar los permisos especiales. El valor octal sería el mismo que el asignado para los permisos normales, es decir entre 0 y 7. He aquí una tabla muy explicita que explica exactamente qué significa cada número:

chmod_especiales

Gracias a esta tabla, podemos asignar los permisos especiales a nuestro antojo y poder asignar uno o varios permisos especiales con total libertad; pudiendo hacer cosas como éstas:

Otorgar sticky bit junto con los permisos 644:
chmod 1644 fichero

Activar el SUID y el SGID en el fichero junto con los permisos 755:
chmod 6755 fichero

Darle el sticky bit y el SUID a un fichero más los permisos 600:
chmod 5600 fichero


Como veis, los permisos especiales son muy útiles y al mismo tiempo peligrosos según el caso, pero es muy conveniente tenerlos presentes, ya sea para evitar escaladas de privilegios accidentales o para prevenir el borrado o renombrado accidental de un fichero.

Espero que os haya sido útil.

Saludos.

sábado, 7 de enero de 2017

Cookies: Qué son y qué podemos hacer con ellas

Hoy quiero hablar sobre uno de los conceptos más famosos de todo Internet; concepto qué en algunos casos nos es mostrado hasta la saciedad: Las cookies. Sí, ese famoso concepto que generalmente vemos al visitar cualquier página web medianamente conocida y/o moderna. ¿Quien no ha visto mensajes parecidos a: "Al entrar a este sitio web, aceptas nuestra política de cookies?" Así es; es raro que no hayamos visto estos mensajes en la actualidad, pero más de uno nunca se ha parado a pensar en lo que ese texto conlleva o, mejor dicho, lo que dichas cookies, o galletitas, suponen.

cookies_portada

Las cookies son una serie de datos, almacenados en formato texto, que contienen datos de la sesión de navegación y los parámetros de configuración de la web, entre otros... Esos datos son creados por los servidores web y luego serían descargados y almacenados por el navegador web y pueden ser usados para hacer un seguimiento de nuestra navegación web. Además, es importante saber que hay más de un tipo de cookie; en concreto habría cinco tipos de cookies:

  • Cookies de sesión: Son aquellas que se eliminan automáticamente al terminar la navegación. 
  • Cookies persistentes: Estas cookies no importa que cerremos la sesión de navegación que seguirán guardadas en nuestro equipo para ofrecernos una experiencia más ágil la próxima vez que se viste la página, ya que guardan los datos de las sesiones, tales como los datos de login o las preferencias de idioma. Este tipo cookies tienen una fecha de caducidad tras la cual se eliminarían automáticamente; la cuestión está en que está que generalmente dicha fecha de caducidad puede ser a muy largo plazo; desde uno o dos años hasta 10,20 años o más... Con lo que hay que tener cuidado, ya que si no limpiamos nuestras cookies a menudo podríamos tener cookies de una enorme antigüedad guardadas en nuestro equipo; cookies que podrían contener información sensible. 
  • Super cookies: No, no son cookies con más información, sino cookies más peligrosas que el resto. Una cookie normal está siempre asociada a un nombre de dominio; ya sea bytelearning o el que sea, pero una super cookie está asociada a extensiones de dominio (.com, .es, .net...). Esto no puede parecer relevante, pero sí que lo es, ya que dichas cookies pueden seguir el "rastro" de una persona independientemente del dominio que visite. Afortunadamente la mayoría de los navegadores más modernos ya bloquean dicho tipo de cookie automáticamente, pero si se estuviese usando una versión antigua de Chrome o Firefox podríamos sin querer "comernos una galleta equivocada".
  • Cookies zombies: Cookies que aún cuando son borradas, son generadas de nuevo debido JavaScript o HTML5.
  • Cookies Flash: Esta "cookie" es un archivo especial usado por las páginas web que implementan Flash. Para bien o para mal, estas cookies cada vez son menos frecuentes, pues hay navegadores que directamente bloquean Flash por defecto; tales como Chrome y Firefox.

Ahora bien; estas cookies que son almacenadas por el navegador, tienen que estar almacenadas en algún lado... ¿Pero donde? La ubicación de éstas dependería de dos factores: El navegador y el sistema operativo. En mi caso me centraré en el sistemas operativos basados en GNU/Linux y los navegadores más populares; Chrome y Firefox.

En chrome:

La ubicación de las cookies, en caso de estar usando este navegador sería:

~/.config/google-chrome/Default/cookies

En Firefox:

En caso de usar este navegador o Iceweasel (que para el caso son prácticamente iguales).

~/.mozilla/firefox/serie_de_numeros_y_letras.default


Ambos tipos cookies pueden ser leídas tanto mediante la consola con sqlite (cosa no demasiado recomendable, debido a que lo mostrado no queda demasiado ordenado) o con sqlitebrowser, que se trata de una aplicación gráfica que muestra dicha información de forma más intuitiva y amigable. Esta última aplicación no estaría por defecto instalada pero su instalación sería algo tan sencillo como:

apt-get install sqlitebrowser

Esta aplicación es muy amigable pero tiene como pega el hecho de que requiere introducir la ruta completa donde se encuentra alojada la cookie; ruta que por defecto está oculta (todo aquello que empieza por . significa que el fichero o directorio está oculto) y que es algo engorrosa de introducir a la hora de querer abrir la base de datos que almacena dichas  cookies. Con lo que si bien este método "global" es muy potente y versátil, lo más cómodo para un usuario final sería revisar las cookies de su navegador especifico con una herramienta más "directa".

Las opciones más amigables serían el uso de extensiones especificas para cada navegador; aquí, como siempre para gustos están los colores, pero la extensión con la que me he sentido más cómodo con cada navegador sería:

  • Firefox: Cookies Manager. Es un gestor de cookies bastante sencillo a nivel visual, pero que cumple con su objetivo; que es el poder visualizar, editar o eliminar nuestras cookies.
  • Chrome: Edit this Cookie. Tiene las mismas funciones que la mencionada antes para Firefox, si bien ésta es algo más atractiva a nivel visual.

cookies_manager
Cookies Manager Iceweasel

Gracias a estas herramientas podemos controlar con gran libertad nuestras cookies, logrando tener cierta noción de las cookies que están siendo descargagadas a nuestro equipo.

Como veis, las cookies es un asunto bastante amplio y completo; aunque afortunadamente hoy en día contamos con gran número de recursos para tenerlas bajo control y saber qué se está descargando nuestro equipo. Además gracias a recursos tales como la navegación privada y/o el no recordatorio del historial, nos pueden ayudar a no almacenar esas cookies persistentes que pueden llegar a ser contraproducentes almacenar dependiendo de nuestras necesidades.

Saludos.

lunes, 2 de enero de 2017

Cómo crear un servidor TFTP en Linux

Hoy quiero traeros un servicio muy usando en la actualidad; especialmente cuando se trabaja con equipos que se descargan la configuración vía red, dispositivos tales como Netgear o Grandstream. Se trata de una variante del servicio FTP, una variante preparada para que los equipos puedan descargarse pequeños archivos (generalmente de configuración) por red, evitando tener que realizar varias tediosas configuraciones y evitando problemas en caso de que alguien optase por restaurar la configuración de fábrica del equipo, pues la configuración siempre estará accesible vía red. Dicho servicio se llama TFTP (Trivial File Transfer Protocol), y una de sus principales ventajas es la facilidad de su configuración.

TFTP_Portada

Lo primero e indispensable para poder preparar nuestro servidor TFTP sería instalar los paquetes necesarios para que éste funcione, para lo cual ejecutaríamos el comando:

apt-get install xinetd tftpd tftp

Más de uno puede sorprenderse al ver que, además de los dos paquetes más obvios, también se está instalando el paquete xinetd. Para aquellos que no conozcan dicho paquete, han de saber que xinetd (eXtended InterNET Daemon) es un servicio que se dedica a controlar algunos procesos que requieren conectividad con Internet, tales como telnet, FTP o TFTP, y que proporciona una serie de configuraciones para mejorar tanto la seguridad del servicio como el consumo de recursos de éste. Es por ello que es altamente recomendable instalarlo junto con los otros dos paquetes con el fin tener un servidor TFTP óptimo.

Tras finalizar la instalación tendremos que desplazarnos al directorio de xinetd que almacena los ficheros de configuración de los servicios que controla; directorio llamado /etc/xined.d; allí dentro no veremos referencia alguna al servicio tftp, con lo que deberemos crear uno dicho nombre (importante que el nombre se encuentre todo en minúsculas); es decir que lo primero de todo que haremos será crear dicho fichero vacío para evitar problemas:

touch /etc/xinetd.d/tftp

Para después modificar dicho fichero para que tenga la siguiente estructura:

  1. service tftp
  2. {
  3. protocol        = udp
  4. port            = 69
  5. socket_type     = dgram
  6. wait            = yes
  7. user            = root
  8. server          = /usr/sbin/in.tftpd
  9. server_args     = /tftpboot
  10. disable         = no
  11. }

Antes de continuar, creo que es importante entender el significado de los parámetros de este fichero de configuración, pues en mi opinión la filosofía del simple copia-pega, sin entender el significado de lo copiado, es poco práctico e incluso peligroso dependiendo del caso.

  • Protocol: Se especifica el protocolo usado para este servicio, lo cual se divide básicamente en dos protocolos: TCP o UDP.
  • Port: Puerto en el que estará en "escucha" el servicio; El puerto por defecto de TFTP es el 69, pero se puede modificar si se desea, ya sea por motivos de seguridad o por cualquier otro motivo.
  • Socket_type: El tipo de socket de este servicio; En este caso se ha puesto dgram, es decir Datagram Socket
  • Wait: A diferencia de lo que uno puede pensar; esto no significa que el servicio TFTP tenga que esperar o no, sino que se dice si el servicio mono-proceso (no) o multi-proceso (yes). Con las CPU de hoy en día, que tienen múltiples núcleos, lo normal sería que todos los servicios sean multi-proceso; es decir que el valor wait sea puesto a yes. Si queréis saber un poco más acerca de los procesadores y los núcleos os recomiendo leer es post que hice en su día sobre el control de la salud del equipo en bash, que incluye algunas referencias a estos puntos.
  • User: El usuario que ejecutará en servicio; lo normal sería que lo ejecute root, pues nos aseguraríamos que el servicio se ejecutaría, si bien esto queda al gusto de cada uno.
  • Server: Aquí se define el binario que va a ejecutar el servicio. Habría que especificar la ruta completa, pues en caso contrario el fichero no lo encontraría.
  • Server_args: Los argumentos extra que añadiríamos a la ejecución del binario; este argumento no siempre es necesario, pero en este caso en concreto sí que lo sería, pues con estos argumentos extra estaríamos diciendo el directorio al que se accedería vía TFTP; directorio aislado que se parecería bastante a los directorios enjaulados de chroot, con la diferencia de que aquí únicamente se podrían realizar transferencias de datos desde otros equipos.
  • Disable: Este parámetro especifica si queremos que este servicio se arranque cuando se inicia xinetd o no. Lo normal es que el servicio se arranque con lo que pondríamos éste parámetro a "no"; en caso de no querer que se inicie, habría que poner dicho valor a "yes".

Con esto entendido y con el fichero de configuración creado, tendríamos que reiniciar el servicio xined para que arranque nuestro servidor tftp:

/etc/init.d/xinetd restart

Con esto ya tednríamos el servicio en marcha; la mejor forma de comprobarlo sería revisando que el puerto 69 está en escucha, con lo que ejecutaríamos el comando:

netstat -putan |grep ":69 "

Tendría que aparecernos una línea parecida a la siguiente:

netstat tftp

Obviamente esta comprobación no bastaría; para empezar el directorio /tftpboot no existe por defecto, y habría que crearlo; además para cerciorarnos de que se hacen las transferencias correctamente, lo ideal sería crear un fichero dentro de dicho directorio para luego descargarnoslo vía tftp. Por ejemplo podríamos crear un fichero llamado fichero.txt.

  1. mdkir /tftpboot
  2. touch /tftpboot/fichero.txt
  3. echo > "1723457" > /tftpboot/fichero.txt
  4. chmod -R 755 /tftpboot

Con todos los preparativos realizados, lo que haríamos sería realizar el test en cuestión, que se podría realizar en el propio equipo o en otra máquina que tenga instalado el paquete tftp. Sería tan sencillo como escribir:

  1. tftp 192.168.1.4
  2. tftp> get fichero.txt
  3. Received 10 bytes in 0.0 seconds
  4. tftp> quit

Las líneas que comienza por tftp> se tratarían  líneas que aparecen en la consola automáticamente haciendo referencia a que nos encontramos dentro de una sesión tftp; sesión de la que se saldría mediante el comando quit.

Con esta prueba, en caso de habernos descargado exitosamente el fichero, verificaríamos que nuestro servidor TFTP se encuentra completamente operativo. Ahora bien... Si os fijáis bien, hasta ahora no hemos realizado algo que se aleje demasiado del funcionamiento de un servidor FTP normal... La mejor forma de sacarle el máximo partido al servidor TFTP es combinarlo con un servidor DHCP que incorpore funciones de TFTP, con el fin de que cuando un equipo coge IP, se descargue su fichero de configuración. Para ello, debemos tener un servidor DHCP instalado; en caso de no tenerlo instalado haríamos:

apt-get install isc-dhcp-server

Ahora pasaríamos a configurar el servidor DHCP para que pase la dirección del servidor tftp (además de la IP) a los equipos para que estos se descarguen la configuración. El fichero de configuración sería /etc/dhcp/dhcpd.conf, y una configuración básica sería:

  1. default-lease-time 600;
  2. max-lease-time 7200;
  3. shared-network "RED"{
  4.     subnet 192.168.1.0 netmask 255.255.255.0 {
  5.         range 192.168.1.5 192.168.1.254;
  6.         option tftp-server-name "192.168.1.4";
  7.     }
  8. }

Con esto estaríamos dándoles IP a los equipos y diciéndoles la IP del servidor TFTP desde el cual tendrían que bajarse el fichero de configuración (si lo hubiera); la cuestión está en que ésto no es del todo realista, sino que lo normal es hacer que ciertos equipos cojan la configuración de un directorio, otros de otro, etc... Es decir que se ponga cierto orden y se apliquen una serie de reglas para evitar que todo quede echo un desastre... Para ello estableceremos una serie de rangos de IP dependiendo del fabricante del equipo que esté pidiendo IP. Imaginemos que tenemos una red con Netgear, Grandstream y PCs de sobremesa. Queremos que los PCs simplemente reciban IP, pero queremos que las dos marcas reciban unas IPs en concreto y que apunten a un directorio en concreto del que descargar la configuración...

Podemos determinar la marca del fabricante gracias los 3 primeros bloques hexadecimales. Por ejemplo sabemos que las MAC que comiencen por "00:0b:82" son de grandstream y que comienzan por "20:4f:7f" son de Netgear; si bien este último fabricante tiene varias MACs. Para conocer con detalle las MACs y sus fabricantes, podéis entrar en esta web: http://www.miniwebtool.com/mac-address-lookup/. Gracias a estas MACs, podemos hilar mas fino, y no solo eso, sino que podemos crear subdirectorios específicos dentro de /tftpboot para estas marcas para que así cada una tenga sus ficheros por separado. Es decir que podemos hacer lo siguiente:

  1. mkdir /tftpboot/grandstream
  2. mkdir /tftpboot/netgear
  3. chmod -R 755 /tftpboot/

Ahora prepararíamos nuestro servidor DHCP para adaptarse a nuestras necesidades; haciendo que el fichero /etc/dhcp/dhcpd.conf quede de forma parecida a la de a continuación:


  1. class "grandstream" {
  2.         match if (
  3.                 (substring(hardware, 1, 3) = 00:0b:82)
  4.         );
  5. }
  6. class "netgear" {
  7.         match if (
  8.                 (substring(hardware, 1, 3) = 20:4f:7f)
  9.         );
  10. }
  11. default-lease-time 600;
  12. max-lease-time 7200;
  13. shared-network "RED"{
  14.         subnet 192.168.1.0 netmask 255.255.255.0 {
  15.                 pool {
  16.                         range 192.168.1.5 192.168.1.50;
  17.                         allow members of "grandstream";
  18.                         option tftp-server-name "192.168.1.4/grandstream";
  19.                 }
  20.                 pool {
  21.                         range 192.168.1.51 192.168.1.100;
  22.                         allow members of "netgear";
  23.                         option tftp-server-name "192.168.1.4/netgear";
  24.                 }
  25.                 pool {
  26.                         range 192.168.1.101 192.168.1.254;
  27.                         allow unknown-clients;;
  28.                 }
  29.         }
  30. }

Gracias a ésto, no solo tendríamos un servidor TFTP funcional, sino que también tendríamos un servidor DHCP completamente configurado que ayudaría a que éste sea útil y efectivo.

Espero que os haya resultado útil.

Saludos.