enero 2010


Cuando empecé a estudiar informática, una de las tareas que menos me atraían era la de desarrollo web, me estoy refiriendo al desarrollo web a palo seco (HTML, javascript, CSS y algo de PHP). Siempre me ha gustado más programar en C/C++ o incluso acostumbrarme a la “facilidad” de hacer las cosas en Java. Tener un IDE completo que te ayude a desarrollar tus aplicaciones, con un buen System.out.println(variable); debugger, un sistema de documentación completo como javadoc o doxygen. Sin embargo, una vez que estás trabajando te tienes que amoldar a las situaciones que te vas encontrando. Al final me ha tocado mantener/desarrollar un portal web basado en Joomla junto con otros compañeros.

Para desarrollar tranquilo, me parece una buena práctica hacer tus modificaciones en el software de una máquina de pruebas y luego desplegarlo en el entorno final de producción. Además, al no desarrollar solo, no sabes si algo de lo que estás tocando puede estropear el código de otros compañeros…

Creo que la mejor forma de conseguir un entorno de desarrollo productivo sin muchas complicaciones del que se puedan extraer snapshots o backups automáticos es hacer uso de varias herramientas de las que disponemos en GNU/Linux: los scripts en Bash, el SSH y CRON. Voy a pegar y comentar el script que utilizo para desplegar periódicamente el portal web de la máquina de desarrollo y pruebas al entorno de producción. Pero antes, he de comentar cómo hacer un ssh sin necesidad de teclear la contraseña.

La idea es que hay que copiar la clave pública del usuario que queremos utilizar (está en $HOME/.ssh/id_*.pub, siendo * el algoritmo utilizado en la creación de la clave, comúnmente RSA o DSA) en el archivo $HOME/.ssh/authorized_keys de la máquina destino. Dicha clave pública se puede pasar por SCP o utilizando un disco duro externo al ordenador de destino. En este caso hipotético, voy a utilizar la clave del ordenador de desarrollo del usuario root para poder hacer ssh sin contraseña a la máquina “servidor” con el usuario abian:

root@desarrollo:~# scp /root/.ssh/id_dsa.pub abian@serverhosting:/home/abian/

abian@serverhosting:~$ cat id_dsa.pub >> .ssh/authorized_keys

Ahí va el script. Lo podéis guardar en un archivo de texto plano llamado “backup_automatico.sh“. No hay que olvidarse de dar los permisos de ejecución a este nuevo archivo utilizando chmod +x backup_automatico.sh:

#!/bin/bash
#Directorio en el que se irán guardando los backups
BACKUPS_FOLDER=/home/abian/bakcups_web/
#si el directorio no existe lo creamos
[ -d “$BACKUPS_FOLDER” ] || mkdir $BACKUPS_FOLDER
#borrar los backup viejunos para no ocupar tanto espacio en el servidor destino
ssh abian@hostingserver ‘rm -rf /home/abian/backups_web/*’
#Paro el apache
/etc/init.d/apache2 stop
#me quedo con la fecha de hoy
DATE=$(date +%d_%m_%Y)
#creo el backup
tar cfj $BACKUPS_FOLDER/web_$DATE.tar.bz2 /var/www/web/
#arranco de nuevo el apache
/etc/init.d/apache2 start
#copiar este último backup al hosting y descomprimirlo
scp $BACKUPS_FOLDER/web_$DATE.tar.bz2 abian@hostingserver:/home/abian/backups_web/
ssh abian@hostingserver ‘cd /home/abian/backups_web/ && tar xfj web_*.tar.bz2’
#algunos datos de la configuración del MySQL
HOST=localhost
USER=root
PASS=changeme
DB=database
#utilizo mysqldump para hacer el volcado de la base de datos a un fichero
mysqldump –add-drop-database -h $HOST -u $USER -p$PASS –databases $DB > $BACKUPS_FOLDER/web_$DATE\_$DB\_full_schema.sql
#el archivo sql puede ocupar mucho a sí que lo comprimo

bzip2 -f $BACKUPS_FOLDER/web_$DATE\_$DB\_full_schema.sql
#lo copio al hosting
scp $BACKUPS_FOLDER/web_$DATE\_$DB\_full_schema.sql.bz2 abian@hostingserver:/home/abian/backups_web/
#Parar el apache remoto
ssh
abian@hostingserver ‘/etc/init.d/httpd stop’
#restaurar los archivos del portal web
ssh
abian@hostingserver ‘rm -rf /var/www/web/*’
ssh
abian@hostingserver ‘mv /home/abian/backups_web/var/www/web/* /var/www/web/’
#arreglar el owner de los archivos por si acaso
ssh
abian@hostingserver ‘chown -R www-data.www-data /var/www/web/’
#restaurar el backup del mysql
ssh abian@hostingserver ‘bunzip2 /home/abian/backups_web/*.sql.bz2’
ssh abian@hostingserver ‘mysql -h 127.0.0.1 -u root -pchangeme schema_destino < /home/abian/backups_web/*.sql &’
#reiniciar el servidor web remoto
ssh abian@hostingserver ‘/etc/init.d/httpd start’
exit

Ahora que tenemos el script preparado, hay que añadirlo al cron para que lo ejecute cada cierto tiempo utilizando el comando crontab -e añadiendo la siguiente línea:

#Minuto hora dia_del_mes mes dia_de_la_semana   comando
0 4 * * 5 /root/backup_automatico.sh

Al hacer un crontab -l se puede ver qué trabajos tenemos en agenda. En mi caso tan solo tengo este trabajo que se ejecutará todos los viernes a las 4:00 de la madrugada:

root@server:~# crontab -l
# m h  dom mon dow   command
#ejecutar el backup todos los viernes a las 4:00 de la mañana
0 4 * * 5 /root/backup_automatico.sh

¿Algunas consideraciones extras?

  • Para no tener problemas de privilegios o configuraciones raras de usuarios y no hacer este post más largo. La clave pública que realmente hipotéticamente exporto al hosting es la clave pública del root (noto como Ramiro está gritando “Noooooooooooooo…”).
  • La máquina de pruebas es un ubuntu server, por lo que se utiliza el comando /etc/init.d/apache2 stop|start mientras que la máquina destino es un CentOS, por lo que se utiliza el comando /etc/init.d/httpd stop|start.
  • El directorio en el servidor remoto /home/abian/backups_web/ debe existir para que el script funcione.
  • Con unas cuantas modificaciones personales se puede adaptar este script para que haga el backup de lo que cada uno quiera.
  • Me queda un poco la sensación de que he mezclado muchas cosas en este post. Tal vez lo podría haber partido en varios para hacerlo más digerible. Pero si habéis seguido mis entradas anteriores, he explicado muchas cosillas que os pueden venir bien. Configuración de un servidor MySQL, SSH o utilidades del cliente ssh. Seguro que con algo de ayuda de la Wikipedia o Google todo el mundo puede entenderlo.

Espero que os haya gustado. Un saludo.

De sobra es conocida por todos la necesidad de disponer de un buen firewall para proteger nuestra red. No pretendo hacer un complejo manual de conexiones TCP/IP o configuración avanzada de iptables, sino que voy a poner como ejemplo un script de iptables que hice hace algún tiempo y lo voy a explicar un poco para que más o menos todo el que lea este post sea capaz de construirse su propio script de iptables en poco tiempo.

La idea general es que iptables es un sistema de filtrado de conexiones en el que nosotros podemos establecer distintas reglas, si una conexión encaja con el patrón que se ha establecido, se toma la medida indicada. Veamos esto con un ejemplo:

#!/bin/bash
#borrar todas las reglas  de todas las cadenas y reiniciar los contadores de estadísticas
iptables -F
iptables -X
iptables -Z
#Con -P se establece la política por defecto en las distintas cadenas
#la politica por defecto siempre es rechazar menos en OUTPUT
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
#Con la siguiente regla permito las conexiones que ya han sido realizadas
# -A INPUT quiere decir que esta regla se concatena a la cadena INPUT
# -p ALL quiere decir que se aplica a todos los protocolos
# -i eth0 es para el interfaz de red
# -m state –state se utiliza para que haga matching con el estado de la conexión
# -j ACCEPT indica que las conexiones que cumplan la regla anterior serán aceptadas
iptables -A INPUT -p ALL -i eth0 -m state –state RELATED,ESTABLISHED -j ACCEPT
#Abro los puertos que necesito para los servicios que están corriendo en este equipo
#   que son HTTP, SSH y FTP
iptables -A INPUT -p tcp -i eth0 -m multiport –dports 20,21,22,80 -j ACCEPT
#Con la siguiente regla permito el trafico en loopback
iptables -A INPUT -i lo -j ACCEPT

Con este sencillo script, todos los puertos de vuestro ordenador aparecerán como cerrados ante un escaneo de puertos y solo se permitirán las conexiones a los puertos 20, 21, 22 y 80. La potencia de iptables es enorme, se pueden establecer reglas para redirección de puertos, establecer zonas desmilitarizadas, filtrar conexiones dependiendo de la dirección MAC o IP de origen o destino, hacer que determinados paquetes sean logueados en un fichero para su posterior análisis…

Para ejecutar el script anterior tan solo hay que copiarlo en un archivo de texto, por ejemplo, iptables.sh, darle permisos de ejecución mediante el comando chmod +x iptables.sh y ejecutarlo desde una shell con permisos de root.

Para comprobar que está funcionando se puede ejecutar el siguiente comando:

root@server:~# iptables -v -L
Chain INPUT (policy DROP 177K packets, 15M bytes)
pkts bytes target     prot opt in     out     source               destination
5580K 2411M ACCEPT     all  —  eth0   any     anywhere             anywhere            state RELATED,ESTABLISHED
15897  943K ACCEPT     tcp  —  eth0   any     anywhere             anywhere            multiport dports ftp-data,ftp,ssh,www
334M  211G ACCEPT     all  —  lo     any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 338M packets, 216G bytes)
pkts bytes target     prot opt in     out     source               destination

Utilizando el modificador ‘-L’ se listan todas las reglas que están definidas. Si además se utiliza el modificador ‘-v’ o verbose, se puede ver la cantidad de tráfico que es capturado por cada regla.

Solo falta por hacer una cosa. Hacer que el script que acabamos de crear se ejecute automáticamente cada vez que se inicia el sistema operativo. Para ello habrá que utilizar el comando update-rc.d o crear un link simbólico como muestro a continuación:

root@server:~# ln -s /etc/init.d/iptables.sh /etc/rc2.d/S99iptables_alberto

¿Algunas recomendaciones extras?

  • Probar siempre de forma intensiva cada una de las reglas que estamos definiendo. Es incluso recomendable que otra persona realice las pruebas para comprobar que no nos hemos dejado ningún hueco abierto. Como siempre, nmap será la herramienta preferida…
  • Como siempre, mantener el software actualizado para estar al día de las actualizaciones de seguridad.
  • Buscar en Internet ejemplos de scripts, hay miles de ejemplos y muchos de ellos están muy bien documentados. No hay que currarse desde cero una DMZ o un sistema de nat, estos scripts ya están por ahí. Sólo hay que entenderlos y adaptarlos a nuestras necesidades (ya sabéis, la filosofía del Open Source).
  • Revisar las estadísticas que genera iptables para ver si alguna regla tiene un tráfico anómalo. También puede ser una buena política utilizar las opciones de registro de iptables para estudiar las conexiones extrañas más despacio.

Espero que os haya gustado este post. Un saludo

Hace un tiempo escribí un post sobre cómo instalar y configurar un servidor SSH. Tal vez sea el momento de ver alguna de las cosas que se pueden hacer una vez que se dispone de dicho servidor. Podéis encontrar la lista completa en el artículo sobre SSH de la Wikipedia:

  1. Obtención de una shell remota: La primera funcionalidad que se nos viene a la mente al pensar en SSH es la de poder obtener una shell en un ordenador remoto. Para ello, hay que utilizar el siguiente comando:

    abian@client:~$ ssh abian@127.0.0.1
    abian@127.0.0.1’s password:

    Una vez que se teclea el password ya estoy trabajando en la máquina remota. Esta utilidad es perfecta para modificar archivos de configuración, reiniciar servicios, revisar logs, etc. Para salir de la shell sólo hay que utilizar el comando logout o exit.

  2. Ejecución de un comando en una máquina remota:

    abian@client:~$ ssh abian@127.0.0.1 netstat -tupan
    abian@127.0.0.1’s password:

    Esta utilidad viene muy bien para ejecutar un comando aislado sin necesidad de obtener la shell.

  3. Copia de ficheros utilizando SCP:

    abian@client:~$ scp /home/abian/test.txt abian@127.0.0.1:/home/abian/probando/
    abian@127.0.0.1’s password:

    Tal vez no parezca muy potente pero si se utiliza la opción ‘-r’ para copiar directorios puede ser la solución definitiva para montar un sistema de backups casero a un servidor remoto:

    abian@client:~$ scp -r /home/abian/motivacionales_4chann/ abian@server:/home/abian/
    abian@127.0.0.1’s password:

  4. Acceso al entorno gráfico remoto: Utilizando la directiva de configuración del servidor ssh de “X11Forwarding yes” se pueden ejecutar aplicaciones que utilicen el entorno gráfico como si estuviéramos sentados delante del monitor del equipo remoto. Si nuestra red no es muy rápida, tal vez sea mejor utilizar soluciones como el servidor NX que funciona bastante bien.
  5. Montar un sistema de ficheros remoto: Se trata de algo parecido a la utilización de NFS para montar un directorio remoto pero en este caso toda la información se tunela utilizando ssh y no hay que instalar ningún servidor extra. Por ejemplo, se puede utilizar la aplicación “connect to server” para montar un directorio concreto:

    Ejemplo de conexión al servidor utilizando ssh

    mount ssh file system

¿Algunas consideraciones extras?

  • Cada vez que nos conectamos a un servidor ssh por primera vez nos pide confirmación sobre la identidad de dicho servidor:

    abian@client:~$ ssh abian@127.0.0.1
    The authenticity of host ‘127.0.0.1 (127.0.0.1)’ can’t be established.
    RSA key fingerprint is d5:0a:28:__:a3:fe:__:53:ba:87:xx:9a:ce:fb:9c:d6.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added ‘127.0.0.1’ (RSA) to the list of known hosts.
    abian@127.0.0.1’s password:

    Una buena política de seguridad nos exigiría comprobar que realmente dicho fingerprint se corresponde con el verdadero. Una vez que lo hemos comprobado, aceptamos la conexión y se crea una entrada en el archivo $HOME/.ssh/known_hosts y no nos volverá a pedir la confirmación más. Sin embargo, si algún atacante mal intencionado intenta hacernos un man-in-the-middle de toda la vida, el comando ssh nos dirá que el fingerprint de la clave ha cambiado y que no se fía de la conexión.

    No siempre son los atacantes mal intencionados los que nos impiden conectarnos por ssh, si se produce una actualización en el paquete sshd de nuestra distribución, se generarán nuevas claves y los fingerprints cambiarán. Habrá que ir al archivo known_hosts y borrar la línea correspondiente al fingerprint antiguo para poder continuar.

  • Es necesario recordar que el puerto por defecto del servidor ssh es el 22 pero que se puede ejecutar en cualquier otro puerto (el 443 es un gran candidato). Para utilizar los comando anteriores apuntando a cualquier otro puerto hay que utilizar el parámetro ‘-p’ para ssh y ‘-P’ para scp.

Espero que os haya gustado el post. Un saludo

Cuando se está trabajando con equipos en una red local, seguro que nos encontramos con la necesidad de permitir que ciertos equipos accedan al disco duro de un equipo remoto. Una de las formas de hacerlo es utilizar NFS (Network File System). Utilizando NFS podemos exportar un directorio de un equipo (servidor) para que sea utilizado por otros equipos (clientes) tanto en modo solo lectura como de lectura-escritura.

Para instalarlo solo hay que teclear el siguiente comando:

sudo apt-get install nfs-kernel-server nfs-common portmap

Para tener una idea de qué acabamos de instalar, puedo deciros que portmap sirve para transformar identificadores de programa RPC en direcciones DARPA. Para ver un ejemplo de funcionamiento, se puede ejecutar el siguiente comando:

abian@server:~$ rpcinfo -p
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
100024    1   udp  39034  status
100024    1   tcp  58076  status
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100021    1   udp  34156  nlockmgr
100021    3   udp  34156  nlockmgr
100021    4   udp  34156  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100021    1   tcp  44829  nlockmgr
100021    3   tcp  44829  nlockmgr
100021    4   tcp  44829  nlockmgr
100005    1   udp  49504  mountd
100005    1   tcp  46117  mountd
100005    2   udp  49504  mountd
100005    2   tcp  46117  mountd
100005    3   udp  49504  mountd
100005    3   tcp  46117  mountd

Por otra parte, nfs-common contiene los binarios necesarios para utilizar el servicio NFS tanto en el cliente como en el servidor (lockd, statd, showmount, y nfsstat). Nfs-kernel-server contiene el soporte para el kernel de linux necesario para poder transformar nuestro equipo en un servidor NFS. Por supuesto, este último paquete no será necesario en el cliente.

Ahora está claro lo que se ha instalado, se puede pasar a la correcta configuración del servidor. Para ello hay que editar tres ficheros.

  1. El fichero /etc/exports contendrá una línea por cada directorio que se desee exportar. Por ejemplo, con el siguiente contenido estaríamos indicando que el equipo con la IP 192.168.10.25 tiene acceso de lectura y escritura al directorio /home/abian/test/ mientras que el equipo con la IP 192.168.10.26 tan sólo tiene acceso de lectura. He utilizado la opción no_subtree_check porque es la opción por defecto para la comprobación de subdirectorios pero puede que no sea la más aconsejable para un entorno de producción:

    abian@server:~$ cat /etc/exports
    /home/abian/test       192.168.10.25(rw,sync,no_subtree_check) 192.168.10.26(ro,sync,no_subtree_check)


    Éste es el ejemplo más sencillo, se puede exportar un directorio a una subred, utilizar opciones de mapeo de usuarios, escrituras asíncronas… Para ver más información y ejemplos útiles recomiendo (como siempre) utilizar el comando man:

    abian@server:~$ man exports

  2. El fichero /etc/hosts.allow contiene las directivas necesarias para controlar qué equipos acceden a qué servicios. En este caso tenemos que incluir dos líneas para que el sistema funcione.

    abian@server:~$ cat /etc/hosts.allow
    portmap:192.168.10.0/255.255.255.0
    nfs:192.168.10.0/255.255.255.0

    Con estas dos líneas estamos indicando que permita el acceso a todos los equipos de la subred 192.168.10.0 a los servicios portmap y nfs.

  3. El último fichero de configuración está relacionado con el anterior pero tiene justo la utilidad contraria. En /etc/hosts.deny hay que escribir las directivas adecuadas para impedir el acceso de algunos equipos a determinados servicios. Para hacer que Ramiro se sienta orgulloso de mi, voy a hacer publicidad de una de las mejores políticas de seguridad que conozco: “Permitir a todos y denegar a unos pocos” “Permitir a unos pocos y denegar al resto”. Por lo tanto en este archivo tan sólo debe aparecer la línea ALL: PARANOID.

    abian@server:~$ cat /etc/hosts.deny
    ALL: PARANOID

El servidor está completamente configurado. Para aplicar los cambios realizados en los distintos archivos de configuración, es recomendable/necesario reiniciar los servicios relacionados:

abian@server:~$ sudo /etc/init.d/portmap restart
abian@server:~$ sudo /etc/init.d/nfs-kernel-server restart

Para hacer una última comprobación se puede utilizar el comando exportfs:

abian@server:~$ exportfs
/home/abian/test
192.168.10.25
/home/abian/test
192.168.10.26

El siguiente paso es probar que realmente lo que hemos configurado funciona. Para ello hay que utilizar alguna máquina cliente (recordando que debe tener la IP 192.168.10.25 o 192.168.10.26) y utilizar el comando:

abian@client:~$ sudo apt-get install nfs-common
abian@client:~$ mkdir test
abian@client:~$ mount -t nfs server  /home/client/test/

Siempre es más cómodo utilizar para estos menesteres el fichero /etc/fstab. La línea necesaria en este fichero sería la siguiente:

server:/home/abian/test /home/client/test nfs timeo=10,intr

¿Algunas recomendaciones extras?

  • Muchos de los problemas de seguridad en las redes de las organizaciones o empresas vienen por el uso incorrecto de los servicios RPC o por vulnerabilidades en dichos servicios. Recomiendo encarecidamente mantener actualizado el software del servidor, tanto del kernel como del resto de los servicios. Además, el firewall se convierte en un elemento más importante si cabe (y sí, cabe) para impedir que se accedan a los servicios nfs y RCP desde el exterior de nuestra red local.
  • El sistema se puede hacer un lío con los identificadores de usuarios si intentamos escribir en el directorio que hemos exportado con un usuario que no existe en el servidor o algo similar. La utilización de un sistema centralizado de credenciales de usuario como LDAP podría solventar esta situación. Pero hasta que saque un rato para escribir un post sobre OpenLDAP os recomiendo la utilización de mappings de usuarios en la configuración del archivo /etc/exports. Utilizando anonuid=190 y anongid=110 podéis hacer creer al sistema que 190 es el user id del usuario anónimo pero puede corresponder al propietario del directorio que se está exportando. Lo mismo sucede con el anongid. El tercer y el cuarto campo del fichero /etc/passwd contienen respectivamente el identificador de usuario y grupo.

Espero que os haya resultado de utilidad. Un saludo

Con el nuevo año también se renuevan las ganas de volver a escribir posts. En este caso voy a explicar algo muy sencillito pero notablemente útil cuando estás administrando una red de equipos.

Uno de los protocolos utilizados para la intercomunicación de equipos informáticos es el protocolo IP o Internet Protocol. Este protocolo define que cada equipo en una red debe estar identificado por un número. Existen dos versiones de este protocolo IPv4 y IPv6. La primera de ellas, IPv4, utiliza números de 32 bits para identificar los equipos, estos números están agrupados en cuatro números de 8 bits cada uno separados por puntos que generan 4 rangos de 0 a 255, por ejemplo, 192.168.1.1. Muchos podrían pensar que el número de IPs versión 4 es enorme y que no se va a acabar nunca, pues esto no es del todo correcto. Está empezando a notarse una preocupación cada vez mayor sobre la imposibilidad de mantener este sistema de numeración, lo cual ha llevado a la aparición de IPv6. Esta nueva versión del protocolo utiliza 128 bits para el direccionamiento, con lo que el espacio de direcciones aumenta enormemente. Además, esta nueva versión del protocolo tiene otras muchas ventajas que tal vez mencione en un nuevo post. Por ahora os dejo simplemente un ejemplo de cómo sería una dirección IPv6 fe80::21f:c6ff:fe85:8997/64. Si tenéis el módulo IPv6 cargado en el kernel de linux os aparecerá esta dirección al teclear el comando ifconfig.

Una vez que he llamado vuestra atención sobre la importancia de las direcciones IP, empezamos a ver el problema de que alguien debe otorgar dichas direcciones a los equipos de una red para que no se repitan y para que funcionen bien, debido a que no todas las direcciones IP son válidas.

La primera aproximación siempre es la de hacerlo a mano. En este caso, el administrador del sistema establece una dirección IP para cada ordenador de la red y todo quedaría resuelto. El problema aparece cuando la red es muy grande o cuando queremos cambiar todos los equipos de la red 192.168.1.X a 192.168.2.X. Para solventar estos problemas se creó el protocolo DHCP.

Este protocolo se encarga de la configuración de IPs de los equipos que lo soliciten. Además, permite configurar opciones extras como la puerta de enlace predeterminada de un equipo o el servidor DNS que utilizarán. Una de las características de IPv6 es la autoconfiguración de la IP, por lo que me voy a centrar en la configuración de un servidor DHCP en IPv4.

Para instalar un servidor DHCP hay que descargarse los fuentes o utilizar algún gestor de paquetes como apt-get o yum. Por ejemplo:

sudo apt-get install dhcp3-server

Una vez instalado, hay que completar el archivo de configuración que se encuentra en /etc/dhcp3/dhcpd.conf como se muestra a continuación:

subnet 162.128.30.0 netmask 255.255.255.0 {
range 162.128.30.30 162.128.30.100;
option domain-name-servers dns.alberto.com;
option domain-name “alberto.com”;
option routers 162.128.30.1;
option broadcast-address 162.128.30.255;
default-lease-time 600;
max-lease-time 7200;
}

Por supuesto, esto es solo un ejemplo. Se pueden establecer opciones por defecto, asignar direcciones fijas a un ordenador con una dirección MAC concreta, asignar subredes distintas dependiendo de la interfaz del servidor DHCP a la que llega la solicitud, etc.

Ahora solo resta reiniciar el servidor:

root@abian:~# /etc/init.d/dhcp3-server restart
* Stopping DHCP server dhcpd3
* Starting DHCP server dhcpd3
root@abian:~#

Para comprobar que realmente funciona, tan solo hay que utilizar una máquina cliente y teclear el comando:

root@alberto:~# dhclient3 [interfaz]

Para que el cliente utilice siempre la configuración por DHCP se puede modificar el archivo /etc/network/interfaces para que contenga algo como lo que muestro a continuación:

abian@shadowland:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

De esta manera, cada vez que se encienda el equipo o que se utilicen los comando “ifup eth0” o “/etc/init.d/networking restart” el equipo solicitará una dirección IPv4 al servidor DHCP.

Al hacer un ifconfig aparecerá la información actualizada. Por supuesto, si hemos utilizado información extra como puerta de enlace predeterminada o servidor DNS podremos hacer más comprobaciones revisando el fichero /etc/resolv.conf o utilizando el comando route -n.

Espero que os haya gustado el post, un saludo a todos y hasta pronto.