Montando nuestro propio servidor (VI)

..... de cómo crear un proxy para denegar el acceso a páginas no deseadas y otras cosillas.....

Lamento el retraso desde el último post, pero después de sufrir la rotura de la motherboard de mi server, llegó la defunción de la pantalla de mi portátil (las buenas noticias nunca viene solas, ya sabéis...). Así que he tenido que demostrar mi autoridad paterna para “tomarle prestado” el sobremesa a mi hijo y reconvertirlo en mi nuevo server. Además de liberarle la Play Station, comprarle un HD externo y bajarle alrededor de unos 40 juegos, claro. Pero la autoridad es la autoridad.....
Lo de quitarle el portátil a mi mujer ha sido harina de otro costal.... “Solo” me ha costado renovar su fondo de armario en tres tardes de rebajas..... En fin, qué voy a contar que no sea sabido del sexo “débil”.....

Esto se acaba amigos... Este es el penúltimo post, y nuestro server quedará listo para revista.... Entre otras cosas porque se acerca la descongelación de Wheezy, y habrá que ver si todo funciona adecuadamente una vez actualizado..... Tranquilo, Frannoe, me buscaré otro blog para hacer la actualización..... Porque mucho me temo que actualizar a Wheezy va a ser algo así como hacer un “Claudia”. 

Sabes a lo que me refiero, 

¿verdad, Frannoe?. 

Yo es que me parto con ella..... 

Lo que le puede llegar a pasar..... 

(Besos, Claudia, no te enfades conmigo)

En este post vamos a tratar de echar a andar un servidor DNS y un proxy en nuestro server.

Llevo semanas dándole vueltas al dichoso servidor DNS. No me considero un experto, pero lo que sé de DNS daría para otro par de post. Y Frannoe, con toda la razón del mundo, me va a mandar a paseo, o peor aún, me va a decir que monte yo mi propio blog..... ¡Ni muerto!
Bromas aparte, un servidor DNS es algo muy útil, pero también es algo que puede traer unos dolores de cabeza tremendos. Voy a describiros la instalación de un servidor DNS muy básico (a prueba de balas), en el que se irá creando una bbdd con los registros de accesos a Internet, acelerando así nuestra navegación.

Por definición, el servidor DNS debería tener también una relación de nuestros dispositivos de red, para no tener que aprendernos de memoria las direcciones ip de éstos.......
.
.
Uhmmmm.....
.
.
Estoooooo.......
.
.
¿Me lo repites?

Veamos. Estoy en una red profesional a nivel nacional.... o internacional, ¿quien dijo miedo?. Tengo que conectarme al servidor de archivos de Brasil, en concreto al servidor 03 de la oficina 1523, para hacer una actualización de seguridad a las estaciones de trabajo del área de contabilidad.....

Una de dos, o tienes una memoria de órdago, o tienes una lista con las IP de tus servidores y máquinas (que cutre....). 

Si hubieses sido un administrador de red previsor, habrías creado una estructura parecida a esta en los nombres de los equipos, por ejemplo:

XXX.TTT.OOOO.NNN

siendo XXX el país, TTT el tipo de máquina, OOOO la oficina y NNN el ordinal. Así, sabrías que el servidor  en cuestión es el BRA.DAT.1523.003, y las estaciones de trabajo del area de contabilidad son BRA.CON.1523.x. Ahora vas y te aprendes de memoria las ip's de estos nombres tan chulos....

¡Oño! ¡Si tengo un servidor DNS! Pues que me diga él la ip..... Vale, pero es que éste no es muy listo que digamos.... O le dices tú cuál es la ip cuando lo montas o te puedes morir eternamente esperando.... Para que funcione adecuadamente nuestro servidor DNS, tenemos que definir dos zonas, una de resolución directa y otra de resolución inversa, y declarar en ellas todos nuestros dispositivos de red.... y ya estamos patinando más de la cuenta.... ¿Hace falta esto para nuestro servidor doméstico? Para que funciones adecuadamente, si. Las zonas se crearán, porque si no el servidor no funciona, pero a lo sencillo, sin complicarnos la vida. Total, si vamos a utilizar forwarders en el servidor (reenviadores, osea, que preguntaremos a otros servidores DNS las direcciones), tampoco es cuestión de montar un ISP propio.....

Así que tecleando: apt-get install bind9

Una vez instalado, procederemos a editar el fichero /etc/bind/named.conf.local. En él vamos a definir nuestras dos zonas comentadas antes, la directa y la inversa.
La zona de resolucion directa está definida por nuestro nombre de dominio (ver post parte II), y la definiremos así:

zone “cosillas.ftp21.net” {
    type master;
    file “/etc/bind/zona.directa”;
    };

La zona de resolución inversa la definiríamos de la siguiente manera. Recordad el rango de red local: 172.16.0.x:

zone “0.16.172.in-addr.arpa” {
    type master;
    file “/etc/bind/zona.inversa”;
    };

Creamos los archivos a partír de los archivos de zonas que vienen predefinidas: el archivo zona.directa a partir de db.local y el archivo zona.inversa a partir de db.127:

cp /etc/bin/db.local /etc/bind/zona.directa
cp /etc/bin/db.127 /etc/bind/zona.inversa

y los modificamos: nano /etc/bind/zona.directa

Explicación:
La primera línea modificada hace referencia a un tipo de registro denominado SOA (Start Of Authority). Este registro define el servidor de nombres con autoridad en la zona y la cuenta de correo del administrador de dicha zona (la @ de la cuenta se sustituye por un punto, ya que la @ representa en DNS el dominio raiz de la zona). Para cada zona, debe existir un y solo un registro de SOA. Los valores definidos debajo de este registro son estándares. No modificar, y sobre todo, no olvidar el punto al final del nombre tanto del servidor como de la cuenta de correo.
La segunda línea define el registro NS (Name Server). Deben existir tantos registros NS como servidores de nombres haya en la zona. Debe definirse el nombre del servidor con formato FQDN (Fully Qualified Domain Name, incluye el nombre del equipo mas el dominio correspondiente). Al igual que en la zona SOA, el punto al final del nombre es importante.
Los registros tipo A añadidos definen las direcciones IP de los equipos que queramos añadir, bien con nombre relativo o con nombre FQDN (o lo que es lo mismo, que asignamos una dirección IP a un nombre de equipo para poder hacer ping, por ejemplo.... Ping server ó ping server.cosillas.ftp21.net).

Igualmente, editaremos el fichero /etc/bind/zona.inversa, definiendo exactamente los mismos registros, pero de la siguiente forma:

Es decir, intercambiamos el nombre y la dirección IP, aunque sólo poniendo el último octeto de la misma.

Bien, esto rula. Ahora bien, este DNS no nos sirve para navegar por internet.... Por nuestra red local navega estupendamente, pero.... ¿sería capaz de resolvernos la dirección IP de Google? La respuesta es: NO. Para resolver esto, se utilizan los forwarders. En sí, no es más que una lista de otros servidores DNS, en los que amablemente, algún chalao de las teclas, sin otra cosa que hacer, se ha dedicado a rellenarlo con registros tipo A, para relacionar las páginas del blog de Frannoe con su dirección IP, por poner un ejemplo. Podemos utilizar los DNS de nuestro proveedor de internet o DNS libres como los de Google. O los de cualquier otro proveedor de internet, que los servidores DNS son de acceso público (excepto los de la CIA, NSA, etc....)
Para añadirlos, editamos el fichero /etc/bind/named.conf.options, y añadimos los que deseemos:

Podemos añadir los que queramos. Lo normal sería utilizar también los DNS de nuestro proveedor de internet. Reiniciamos el DNS, y verificamos su funcionamiento: /etc/init.d/bind9 restart

Tendremos que instalar el siguiente paquete antes de hacer pruebas: apt-get install dnsutils. Una vez instalado, tecleamos dig www.debian.org

Dig es un comando que nos da mucha información de los DNS de una dirección determinada. En este caso, nos esta dando la IP del registro tipo A de la dirección indicada, y los registros tipo NS de la misma. Pero lo que nos interesa ahora es ver el tiempo utilizado para la búsqueda. Vemos que tarda 238 milisegundos. Repetimos: dig www.debian.org

Et voilá!!!!
Ya vamos reduciendo el tiempo de búsqueda.... Nuestro querido server ya está empezando a crear su bbdd, y los accesos a las páginas que más utilicemos serán algo más rápidos....

Ea, pues ya que tenemos nuestro DNS en marcha y rulando, toca modificar el pool de DHCP para indicar nuestro servidor DNS. Editamos el archivo: nano /etc/dhcp/dhcpd.conf

Sólo debemos modificar la linea siguiente:

option domain-name-servers 172.16.0.1;

Reiniciamos el DHCP, renovamos la IP en nuestro equipo de sobremesa y verificamos si funciona: /etc/init.d/isc-dhcp-server restart

Para verificar su funcionamiento, voy a utilizar de nuevo el comando DIG, esta vez desde mi equipo, y utilizaremos el lado oscuro para ver si funciona (tranquilos, que no se rompe nada por teclear lo siguiente): dig www.microsoft.com

Repetimos.......

Como véis, las búsquedas dns son instantáneas una vez que se ha añadido la dirección web a la base de datos de nuestro DNS. Así, la navegación hacia esa página es, como mínimo, 106 ms más rápida con nuestro server..... (si no os parece mucho, decirle a Fernando Alonso que le quitamos ese tiempo por vuelta a Vettel, a ver qué os dice....)

Una vez instalado nuestro DNS, vamos a ahora a por el proxy. Tecleando: apt-get install squid

Su archivo de configuración (/etc/squid/squid.conf) es extensísimo y viene con multitud de opciones comentadas y ejemplos. Vamos a olvidarnos de él, crear uno propio y vamos a ir introduciéndole una serie de parámetros.

mv /etc/squid/squid.conf /etc/squid/squid.old
nano /etc/squid/squid.conf

Por defecto, el puerto donde escucha squid es el 3128. A mí personalmente, me gusta más el 8080.

http_port 8080

Para cinco equipos que tengo en red, voy a dejar la cantidad de memoria RAM dedicada a almacenar los datos en 50 MB.

cache_mem 50 MB

El uso de swap viene comentado en los parámetros cache_swap_low y cache_swap_high. Lo dejamos entre el 90 y el 95

cache_swap_low 90
cache_swap_high 95

El parámetro maximum_object_size marca el tamaño máximo de objetos a guardar en la cache. Lo dejaremos en 10240 KB

maximum_object_size 10240 KB

El parámetro hierarchy_stoplist indica a squid qué páginas NO deben almacenarse en caché. Se puede establecer que las páginas que tengan determinados caracteres no se guarden. Por norma general, no se guarda nada a lo que se tenga acceso por https (páginas de webmail, bancos, etc...)

hierarchy_stoplist cgi_bin ? https

En el parámetro cache_dir, establecemos el tamaño de la cache en el disco. Se le indica, tamaño (en MB), directorios subordinados y niveles dentro de cada subdirectorio. Como norma básica viene definido 100 MB 16 directorios y 26 niveles. Aumentaremos el tamaño a 700 MB:

cache_dir ufs /var/spool/squid 700 16 256

El parámetro access_log especifica en qué directorio se realiza el registro de acceso

access_log /var/log/squid/access.log squid

El parámetro cache_log especifica donde se guarda el log de la actividad de squid.

cache_log /var/log/squid/cache.log

Y ahora llegamos al meollo de la cuestión, los filtros. El funcionamiento de Squid es muy sencillo: primero establecemos una o varias listas de control de acceso (ACL), y luego aplicamos determinados filtros sobre ellas. Así, yo crearé dos ACL, una para mis hijos, y otra para el resto de equipos.

Para definir la ACL de los equipos, utilizaremos la denominada SRC.

SRC define una o varias direcciones IP o un rango de direcciones con su mascara de red.
Definiremos tres ACL: la global, la de las direcciones permitidas y las que queremos controlar:

acl all src 0.0.0.0/0.0.0.0
acl redlocal 172.16.0.10 172.16.0.11 172.16.0.12 172.16.0.13 172.16.0.14
acl hijos src 172.16.0.50 172.16.0.60
ó
acl redlocal “/etc/squid/direcciones_permitidas”
acl hijos src “/etc/squid/direcciones_controladas”

siendo hijos y redlocal los nombres que le he dado a las ACL's, y sirviendo para dar acceso al exterior a las direcciones IP que he definido, bien introduciéndolas directamente o bien insertándolas en un archivo de texto (direcciones_permitidas / direcciones_controladas)

Así, si mi querido hijo (el que me ha “prestado” su ordenador) me trae unas notas que no sean aceptables, con eliminar la IP de este archivo, se quedará sin acceso a Internet.

Una vez definida las ACL que van a tener acceso al exterior, se le aplican los filtros que deseamos. Voy a ir a lo sencillo, bloquear páginas que contengan determinadas palabras. Es el filtro más sencillo de aplicar, aunque existen otros, que se pueden combinar entre sí.

acl sitios_denegados url_regex “/etc/squid/denegados”

Para ello, definiremos en un archivo simple de texto, las palabras que deseamos bloquear:

y así con todas las que deseemos. Una vez finalizada, asignamos esta regla a la acl de mis hijos y establecemos acceso libre a la otra ACL:

http_access allow redlocal
http_access allow hijos !sitios denegados

quedando el archivo de la siguiente manera:

Como siempre que modificamos algún archivo de configuración, reiniciamos el servicio: /etc/init.d squid restart

Ahora tenemos que forzar a los navegadores de nuestros dispositivos para que utilicen el proxy. Podemos hacer que nuestro proxy sea transparente, utilizando para ello IPTABLES, pero lo veremos en el último post. Ahora mismo, como ya he dicho, modificamos la configuración de nuestros navegadores para utilizar el proxy.

Para verificar si funciona, he modificado el archivo denegados, añadiendo la palabra facebook, y modifico la ACL hijos, añadiendo la IP de mi portátil. Reinicio squid e intento acceder desde mi portátil a www.facebook.com, sucediendo lo siguiente:

Ea, pues ahora, a currarse el archivo denegados..... Tener en cuenta que no permitirá el acceso a ninguna página que contenga alguna de las cadenas de texto alfanumérico que introduzcáis en dicho archivo. Es decir, si se os ocurre añadir la palabra com en este archivo, no accederá a ninguna página cuya extensión sea .com

Bueno, me despido de vosotros hasta la publicación del último post de la serie. Prometo intentar terminarlo antes de que se descongele Wheezy.

Un saludo a todos.