ceu-notes/TFC/tfc-naortega.tex

\documentclass[11pt,a4paper,titlepage]{article}
\usepackage[spanish,es-tabla]{babel}
\usepackage{csquotes}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{subcaption}
\usepackage{xcolor}
\usepackage{minted}
\usepackage{enumerate}
\usepackage{fancyhdr}
\usepackage[
	backend=biber,
	style=apa,
	sorting=nyt,
	hyperref
]{biblatex}
\pagestyle{fancy}

\definecolor{LightGray}{gray}{0.9}

\addbibresource{tfc-naortega.bib}

\fancyfoot[LO]{{\it Angelus Custos}\linebreak}
\fancyfoot[RO]{\includegraphics[width=0.2\linewidth]{imgs/CEU-Logo-CEP-web.png}}
\setlength{\headheight}{15pt}
\setlength{\footskip}{45pt}

\renewcommand{\familydefault}{\sfdefault}
\renewcommand{\baselinestretch}{1.5}

\title{Sistema de Protección Parental: Angelus Custos}
\author{
	Alumno: Nicolás A. Ortega Froysa \\
	Tutor: Indalecio García Mateos \\
	Centro: CEU San Pablo Andalucía \\
	Ciclo: Administración de Sistemas Informáticos en Red
}

\date{
	\today \\ \bigskip \bigskip
	\includegraphics[width=0.5\textwidth]{imgs/CEU-Logo-CEP-web.png}
}

\begin{document}
\maketitle

\tableofcontents
\pagebreak

\section{Introducción}

{\it Angelus Custos} (i.e.\ Ángel de la Guarda) es un proyecto para facilitar a
los padres la protección de la inocencia de sus hijos ante la degeneración de la
pornografía. Se trata de una solución que cualquier persona con un mínimo de
conocimiento técnico lo puede montar en su casa para proteger a sus hijos, y
también compartir la misma tecnología con otros padres, en espíritu solidario
cristiano, para que ellos también puedan proteger a los suyos.

También optaremos, en este mismo espíritu colaborativo, por soluciones software
que sean libres y gratuitos, ya que el objetivo es proveer una solución para
personas particulares, y no un plan de negocio.

\section{Contexto}
\subsection{Situación Actual}

Vivimos en un mundo muy digitalizado donde los niños están expuestos a
pornografía desde una edad muy temprana (\cite{avg-age}). Aunque hay muchos
factores que contribuyen a esto, uno de ellos es la facilidad de acceso: que un
niño puede encontrarse con contenido pornográfico en la web sin querer, haciendo
una búsqueda completamente inocente o incluso por culpa de anuncios
inapropiados. Aunque diferentes organismos han intentado mitigar esta
posibilidad con soluciones como las {\em búsquedas seguras} en los buscadores,
no ha sido suficiente.

A causa de esto se han creado muchas alternativas para bloquear pornografía en
entornos familiares, educativos, religiosos, etc. Estas alternativas han llegado
incluso a ser muy avanzados, pudiendo reconocer contenido pornográfico con
reconocimiento de imágenes, y enviando reportes a los responsables, que pueden
ser los padres o, en casos de adultos que quieren ayuda para librarse de su
adicción a la pornografía, un amigo o familiar que se responsabiliza. Muchos de
éstos han conseguido convertirlo en un negocio para poder así hacer este tipo de
mejoras y desarrollos a sus productos. (\cite{blocker-alts})

Aunque existen todas estas soluciones, parece que hay pocos que se interesan por
el daño que provoca la pornografía en nuestra salud mental, particularmente en
la salud de los menores de edad. Una parte puede ser la falta de información: es
un asunto que se habla poco debido a su naturaleza clandestina y pervertida.

% TODO: efectos negativos de la pornografía

Otra barrera que puede aparecer es también que estos productos/servicios suelen
funcionar en base a una suscripción mensual. Si fuera un producto que se compra
una sola vez entonces quizá habría más padres dispuestos a instalarlo en sus
casas para proteger a sus hijos. Pero al ser una suscripción, pone una barrera
innecesaria a la hora de facilitar a los padres este servicio tan necesario en
el mundo de hoy.

\subsection{Justificación}

Como explicamos anteriormente, es necesario una solución para protegernos -- a
nuestros hijos, pero también a nosotros mismos -- de la presencia y facilidad de
acceso a la pornografía en {\it internet}. Pero la mayoría de las soluciones son
comerciales y en base a una suscripción, que constituye una barrera para muchos
padres aunque sea tan sólo una inconveniencia. Por este motivo el objetivo de
este documento es explicar cómo montar y configurar un ordenador cualquiera para
servir de monitor y bloquear las páginas pornográficas, además de añadir otras
funcionalidades para mejor administrarlo. De este modo, siguiendo la filosofía
de compartir del {\em movimiento software libre}, se puede conseguir facilitar a
muchos el acceso a esta clase de soluciones o directamente en el caso de las
personas que tengan algún conocimiento técnico, o de manera indirecta con el
caso de alguien que se lo monta para sus familiares, amigos, y vecinos, o
incluso si una empresa lo quiere comercializar de una forma que no ponga sobre
los clientes un peso innecesario de suscripciones para poder protegerse a ellos
mismos y a sus familias.

\section{Planificación y Costes}
\subsection{Metodología}
\subsection{Fases del Proyecto}
\subsection{Planificación Temporal}
\subsection{Estimación de Costes}
\section{Desarrollo}
\subsection{Análisis de Requisitos}

Podemos dividir los requisitos de nuestro proyecto en dos categorías
principales: {\it hardware} y {\it software}.

\subsubsection{Requisitos Hardware}

En cuestión de requisitos {\it hardware}, será necesario un ordenador tan sólo
lo suficientemente potente como para responder a peticiones DNS en una red
local, responder a una petición a una página pornográfica con una página
personalizada del usuario, y enviar correos electrónicos para avisar al
responsable del dispositivo y de la red. Luego entonces, para una red normal, un
requisito mínimo para el dispositivo podría ser como a continuación:

\begin{itemize}
	\item Conexión a la Red: Ethernet
	\item CPU: 1,5GHz con 2 cores
	\item Memoria: 2GB
	\item Almacenamiento: 16GB
\end{itemize}

Los requisitos son muy básicos, y casi cualquier ordenador (incluso uno antiguo
que ya no se usa) serviría para la implementación de esta solución. En caso de
que no haya un ordenador libre a su disposición, convendría más comprar un
ordenador {\it monoplaca}, como sería un {\it Raspberry Pi}, {\it Rock64}, o
{\it Pine64}. Lo importante para nuestros propósitos es que sea posible instalar
en él un sistema operativo basado en UNIX tal como sería una de las
distribuciones de BSD o Linux.

Para la instalación sistemática de este producto no nos conviene utilizar un
ordenador con demasiados componentes, ya que esto crearía demasiados puntos de
fallo, y haría más difícil la instalación. Lo más simple y rápido es utilizar,
como mencionamos anteriormente, un ordenador {\it monoplaca}. De esta manera el
consumo eléctrico será mínimo y la instalación será más simple. La instalación
de un sistema operativo es también más fácil ya que la mayoría de este tipo de
ordenadores utilizan una tarjeta SD para almacenamiento y arranque de sistema;
implica que se puede instalar anteriormente nuestra solución en una tarjeta SD y
luego simplemente insertarlo en su lugar en la placa e iniciar el ordenador.

\begin{table}[h]
	\centering
	\begin{tabular}{|c|c|c|}
		\hline
		{\bf Modelo} & Rock64-4GB SBC & RPi 4 Model B\\ \hline
		{\bf CPU} & 1,5GHz con 4 cores & 1,8GHz con 4 cores \\ \hline
		{\bf Memoria} & 4GB & 4GB \\ \hline
		{\bf Precio} & 40,82€ & 82,02€ \\ \hline
	\end{tabular}
	\caption{Comparación de placas Pine64 y Raspberry Pi. (\cite{pine64};
	\cite{rpi-b}; \cite{rockchip})}
	\label{tbl:compare-boards}
\end{table}

Entre las distintas opciones para ordenadores {\it monoplaca}, tenemos algunos
ejemplos como los que mencionamos anteriormente y muchos más. Realmente hay poca
diferencia entre las opciones -- especialmente respecto a los requisitos tan
simples --, y algunos componentes (como el almacenamiento) dependen más bien del
tamaño de tarjeta SD que compremos. La diferencia principal viene a ser cuál es
el precio de cada placa respecto a las características que tiene. Entre estas
opciones que mencionamos, el Pine64 ya no está disponible, así que las opciones
que vamos a considerar serán el Rock64 y el Raspberry Pi.

En la tabla \ref{tbl:compare-boards} podemos ver una comparación entre dos
modelos similares, uno de Rock64 y otro de Raspberry Pi, comparando sólo
aquellas características que nos interesan. Teniendo que elegir uno de éstos
para nuestra solución, vemos que el {\it RPi 4 Model B} proporciona una mejora
de rendimiento pequeña respecto al {\it Rock64-4GB SBC} en cuestión de CPU --
0,3GHz más -- pero tiene un precio mucho más alto, con 41,2€ de diferencia, o el
doble de precio. Esto seguramente se debe a que el {\it RPi 4 Model B}
proporciona muchas más características y capacidades en otros aspectos que el
{\it Rock64-4GB SBC}, particularmente en cuestión de capacidad gráfica (e.g.\
tiene dos puertos de HDMI para utilizar dos monitores a la vez). Pero esto no
nos interesa, y son cosas que no merece la pena pagarlas si no las vamos a
utilizar. Por este motivo, el modelo que vamos a utilizar sera el {\it
Rock64-4GB SBC}.

\subsubsection{Requisitos Software}

Luego, en cuestión de requisitos {\it software} haría falta, en primer lugar, un
sistema operativo tipo UNIX que soporte a todo el {\it software} que
mencionaremos después. Se puede utilizar este guía para montar la solución con
cualquier otra distribución de Linux (o incluso de BSD), aunque modificando
ciertas instrucciones para ajustarse a los estándares y herramientas disponibles
en cada distribución (e.g.\ si quisiera instalarlo en un servidor de Fedora,
utilizaría el comando {\tt dnf}, mientras que en un servidor Ubuntu utilizaría
{\tt apt}).

En nuestro caso, los criterios para la selección de una distribución son los
siguientes:

\begin{itemize}
	\item {\bf Conocida:} Es importante que sea una distribución conocida y de
		uso amplio. Esto aumentará la probabilidad de que cualquier problema que
		se encuentra, es más probable que otra persona con el mismo entorno (o
		similar) lo haya encontrado también y hayan publicado una solución.
	\item {\bf Estable:} Nuestra solución ha de ser algo que el administrador de
		la red puede instalar y luego mantener la más mínima interacción. Luego
		entonces no son buenas las distribuciones que tengan muchas
		actualizaciones, poco probadas, o propensas a romper el sistema.
	\item {\bf Soporte amplio de plataformas:} Es mejor que nuestra solución se
		pueda instalar en casi cualquier ordenador con las capacidades
		expresadas en el apartado anterior. Y hoy en día se hayan muchos
		ordenadores de arquitecturas distintas a la conocida x86 y x86\_64; la
		más popular de éstas siendo ARM. Una distribución que tenga un soporte
		por muchas arquitecturas contribuiría a la universalidad de la solución.
	\item {\bf Minimalista:} No ha de ocupar mucho espacio de disco/memoria, ni
		tampoco utilizar demasiados recursos. En primer lugar, porque así
		facilita que se pueda instalar nuestra solución en ordenadores más
		viejos o de pocos recursos. En segundo lugar, porque este dispositivo
		sólo hará una cosa, y es mejor reservar recursos para eso en vez de
		añadir más componentes a un sistema complejo que puede causar fallos
		inesperados e innecesarios.
	\item {\bf Utilizada en servidores:} Realmente la solución que proponemos es
		un servidor, específicamente un servidor de DNS con algunos mecanismos
		de filtrado. La distribución que usemos ha de ser conocida por ser
		utilizada en servidores. Esto también ayudará a la hora de evaluar los
		criterios anteriores, ya que las distribuciones ampliamente utilizadas
		en servidores suelen cumplir también aquellos criterios.
\end{itemize}

Para simplificar, en cumplimiento con el primer criterio nos centraremos
solamente en las distribuciones de Linux. Esto se debe a que, de los demás
sistemas operativos basados en UNIX (e.g.\ BSD) no hay un uso tan extenso, y
realmente forman una parte mínima del mercado, aunque tengan especialidad
(algunos) en servidores (\cite{srv-market-share}).

Entre las distribuciones de Linux, los que más se destacan son los siguientes:

\begin{itemize}
	\item Ubuntu Server
	\item Debian GNU/Linux
	\item OpenSUSE
	\item CentOS
	\item Fedora Server
\end{itemize}

De todas estas opciones, la que más se ajusta a nuestros criterios viene a ser
Debian GNU/Linux. Aunque otras opciones, como Ubuntu Server o CentOS son más
corporativas, y Ubuntu también siendo muy conocida, Debian nos trae estabilidad,
pero sobre todo un soporte amplio de plataformas -- soporte oficial para diez
arquitecturas, y no oficial para otras diez (\cite{debian-archs}) --, además de
ser una distribución que permite una instalación mínima (particularmente sin
entorno gráfico). Por este motivo, avanzamos utilizando Debian GNU/Linux. Dicho
esto, Debian en sí no tiene mucha documentación acerca de su instalación en
dispositivos ARM (como lo es nuestra placa Rock64) y por lo tanto seleccionamos
un derivado de Debian GNU/Linux que se denomina Armbian, que distribuye lo que
son básicamente imágenes de Debian especializadas para distintas placas.

En cuanto a los programas que se precisan, haría falta un programa para
gestionar las peticiones DNS y redirigirlas, otro para recibir las peticiones y
responder con una página de aviso, además de disparar un mecanismo para avisar
al administrador de la red acerca del intento de acceso.

Para la gestión de peticiones DNS existen muchos programas alternativos a
nuestra disposición, como podrían ser PowerDNS, MaraDNS, NSD, KnotDNS, y Bind9.
Aquí hay una variedad muy amplia de opciones, y lo que nosotros precisamos es
realmente muy sencillo. La única funcionalidad que nos hace falta es redirigir
ciertas direcciones DNS al mismo servidor con una página estándar, y que las
demás peticiones sean adelantadas a un servidor de DNS normal como la de Google,
con dirección {\tt 8.8.8.8}. Por este motivo seleccionamos la más familiar y
sencillo, siendo Bind9, también denominado {\it Named}. Está presente en todas
las distribuciones más conocidas de Linux bajo el nombre de {\it bind}, {\it
bind9}, o {\it named}.

También nos hace falta tener un recurso que contenga una lista de páginas
prohibidas que se vaya actualizando, y que nosotros opdamos ir descargando y
actualizando de manera sistemática y frecuente. Esto es necesario ya que siempre
pueden haber nuevos dominios que queramos bloquear, y no es posible mantener una
lista estática de este género. En esto podemos hacer uso de las listas negras de
la Universidad de Toulouse (\cite{blacklists}), que contiene varias categorías
de dominios que se pueden bloquear, entre ellas las categorías que nos interesan
serían las de <<adult>>, <<lingerie>>, <<mixed\_adult>>, y
<<sexual\_education>>, además de otras categorías que podrían ser de interés al
usuario (e.g.\ <<agressif>>).

Entre los programas de servidores HTTP existen dos candidatos principales: Nginx
y Apache. Aunque si quisiésemos instalar nuestra solución en una máquina de
{\it Microsoft Windows} se podría contemplar {\it Microsoft Internet Information
Services} (IIS), pero esta opción no esta disponible en Debian GNU/Linux -- o
realmente cualquier sistema operativo que no sea {\it Microsoft Windows}. Para
lo poco que hará nuestro servidor HTTP local, tanto Nginx como Apache podrán
cumplir con los requisitos: servir páginas HTML y pasar peticiones (i.e.\ {\it
requests}) HTTP a un {\it script} para gestionarla; así que la elección es
arbitraria. Es verdad que, en cuestión de gestión de contenidos estáticos, Nginx
tiene una ventaja sobre Apache, pero en cuanto a la gestión de contenidos
dinámicos (i.e.\ páginas dinámicas que se gestionan a partir de {\it scripts})
apenas hay diferencia entre las dos opciones (\cite{nginx-vs-apache}).
Escogeremos a Nginx simplemente por el criterio de mayor conocimiento y
experiencia con su uso y administración.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.4\textwidth]{imgs/ss-lang-stats.png}
	\caption{Estadísticas de uso de lenguajes de \\ programación en el lado
	servidor. (\cite{sv-lang})}
	\label{fig:ss-lang-stats}
\end{figure}

Finalmente, precisamos un lenguaje de programación por el cual podemos enviar un
correo al administrador de la red con la información pertinente del intento de
acceso a un sitio web prohibido (i.e.\ pornográfico). Para esto existen varias
alternativas hoy en día, las principales siendo PHP, Ruby, Python, y JavaScript
(por medio de NodeJS). De estas opciones la más utilizada en servidores, sin
competición alguna -- ocupando un 77,5\% del mercado -- es PHP (figura
\ref{fig:ss-lang-stats}). Es muy fácil de incorporar a un servidor HTTP, la
mayoría (como Nginx) tienen formas de incorporarlo como un módulo, y otros
servidores lo tienen directamente incorporado (como el caso de Apache). Tiene
también un interprete ligero, y es muy estable. Por estos motivos, el lenguaje
que utilizaremos será PHP.

Con el lenguaje de programación PHP existen varios métodos de enviar correos, y
aunque existe la función por defecto de PHP, {\tt mail()}, no queremos
utilizarlo ya que es demasiado simple y no soporta el protocolo SMTP, que sería
útil para enviar correos a una dirección personal sin que aparecieran como {\it
spam}. Lo que quiere decir que tendremos que utilizar un módulo de terceros para
gestionar el envío de correos. Para esto conviene un módulo que esté disponible
y de fácil instalación en nuestro sistema. En esto la opción más conveniente
sería {\it PHPMailer}. Aunque {\it Symfony Mailer} sería otra opción que se
utiliza mucho con PHP, no esta disponible en los repositorios de Debian
GNU/Linux, como PHPMailer, y por lo tanto sería más difícil de instalar y
actualizar, sobre todo el proceso de una actualización automática.
(\cite{mail-methods}; \cite{debian-pkgs})

\subsection{Diseño de Solución}

\begin{figure}[h]
	\centering
	\includegraphics[width=0.75\textwidth]{imgs/network-map.png}
	\caption{Mapa de red con servidor {\it Angelus Custos} instalado.}
	\label{fig:network-map}
\end{figure}

Nuestra solución consiste en tener un servidor que sirve de {\em filtro} para
todas las peticiones DNS de nuestra red local. Generalmente se puede dividir en
dos partes esenciales:

\begin{itemize}
	\item Filtrado de peticiones DNS, redirigiendo aquellas peticiones no
		permitidas al mismo servidor para responder un una página estándar.
	\item Un sistema de administración para enviar una notificación al
		administrador de la red acerca de qué dispositivo ha intentado
		conectarse al dominio prohibido, y qué dominio ha sido.
\end{itemize}

Como visualización gráfica, podemos fijarnos en la figura \ref{fig:network-map},
que muestra una distribución básica de la red. El servicio DHCP de nuestra red
ha de tener configurado a la dirección IP de nuestro servidor {\it Angelus
Custos} como servidor DNS. Esto generalmente se encuentra dentro de la
configuración del {\it router}, que suele encargarse en el mismo dispositivo de
las tareas de servidor DNS, DHCP, {\it switch}, y enrutador.

Cada vez que un cliente de nuestra red quiera acceder a un servidor por su
nombre de dominio (e.g.\ example.com) pedirá a nuestro servidor la resolución de
aquel nombre a una dirección IP. Si el dominio no se encuentra dentro de la
lista negra de sitios prohibidos se adelantará la petición a un servidor DNS
externo (e.g.\ Google en la dirección {\tt 8.8.8.8}) y seguirá la ruta normal.
Mas en el caso de que estuviera el nombre en la lista negra, nuestro servidor
devolvería su propia dirección IP para que así se conecte el cliente a nuestro
{\it script} que avisará al administrador y bloqueará el contenido, mostrando
nada más que una página estática con un texto predeterminado, avisando de que la
página está bloqueada y el administrador ha sido avisado.

\section{Pruebas y Despliegue}
\subsection{Plan de Pruebas}

Una vez montada la solución, hemos de probar que funciona correctamente. Sería
también conveniente hacerlo sin necesidad de visitar ninguna página {\it web}
prohibida.

Lo primero sería verificar que se ha configurado correctamente nuestro servidor
DHCP (normalmente en el propio {\it router}) para asignar nuestra solución como
servidor DNS de la red. Para verificar esto nos conectamos a la red por medio de
un ordenador ajeno y vemos cuál es el servidor DNS que nos ha dado.

Si nuestra máquina de pruebas es también un sistema de Debian GNU/Linux,
entonces podemos asegurarnos de que hemos pedido información del servidor DHCP
utilizando el comando siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{console}
# dhclient -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s8/08:00:27:5f:48:3a
Sending on LPF/enp0s8/08:00:27:5f:48:3a
Listening on LPF/enp0s3/08:00:27:16:c6:22
Sending on LPF/enp0s3/08:00:27:16:c6:22
Sending on Socket/fallback
DHCPREQUEST for 192.168.0.104 on enp0s8 to 255.255.255.255
port 67 (xid=0x4dcd9939)
DHCPREQUEST for 192.168.0.108 on enp0s3 to 255.255.255.255
port 67 (xid=0x606bc4b3)
DHCPACK of 192.168.0.104 from 192.168.0.1 (xid=0x3999cd4d)
\end{minted}

Luego podemos verificar cuál es la dirección IP del servidor DNS configurado
mirando el archivo {\tt /etc/resolv.conf}:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{console}
# cat /etc/resolv.conf
nameserver 192.168.1.135
\end{minted}

Si la dirección IP que muestra coincide con aquella que corresponde a nuestro
servidor entonces sabemos que el servicio de DHCP se ha montado correctamente.

Ahora, para asegurarnos de que se ha configurado correctamente nuestro servidor
también como filtro de DNS, tan sólo hace falta correr el comando {\tt
nslookup}, que se puede encontrar en el paquete de Debian denominado {\tt
bind9-dnsutils}. Con esto verificamos cuál sería la respuesta si alguien de la
red quisiera acceder a una de las páginas prohibidas en nuestra red. Debería de
devolver una respuesta de la forma siguiente, asumiendo que la dirección IP de
nuestro servidor es {\tt 192.168.1.135}:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{console}
# nslookup porn.com
Server:     192.168.1.135
Address:    192.168.1.135#53

Non-authoritative answer:
Name:   porn.com
Address: 192.168.1.135
\end{minted}

Si la salida sale así, hemos podido verificar el funcionamiento correcto de
nuestra solución, y sin conectarnos siquiera a un servidor que provee el
contenido bloqueado.

\subsection{Manuales Técnicos y de Usuario}

\subsection{Plan de Despliegue}

Para desplegar nuestra solución haría falta seguir los siguientes pasos:

\begin{enumerate}[i.]
	\item Instalar el sistema operativo (Armbian).
	\item Configurar la red.
	\item Instalar y configurar el servicio DNS (Bind9).
	\item Instalar y configurar el servicio web (Nginx).
	\item Instalar la página PHP que enviará avisos al administrador de la red.
\end{enumerate}

\subsubsection{Instalación de Armbian}

Para la instalación de Debian GNU/Linux en nuestro servidor, como utilizamos la
placa de Rock64 es tan fácil como preparar la tarjeta SD con una imagen de
Armbian, que se puede descargar en su sitio web en la página
dedicada a la placa Rock64.\footnotemark{} Una vez descargada lo podemos descomprimir e instalar
utilizando los comandos siguientes, asumiendo que en tu ordenador el dispositivo
de la tarjeta SD corresponde al fichero especial {\tt /dev/mmcblk1}:

\footnotetext{\url{https://www.armbian.com/rock64/}}

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{console}
# unxz Armbian_<version>_Rock64_<codename>_current_<version>.img.xz
# dd if=Armbian_<version>_Rock64_<codename>_current_<version>.img \
    of=/dev/mmcblk1 bs=1M
\end{minted}

Al acabar este paso ya podemos insertar la tarjeta SD en nuestro Rock64 y
empezar a configurar la red.

\subsubsection{Configuración de Red}

Cuando hayamos inicializado nuestro servidor y estemos dentro, lo primero que
queremos hacer es configurar la red para utilizar una dirección estática. Esto
se hace manipulando el fichero {\tt /etc/network/interfaces}. Ahí nos aparecerá
algo parecido a lo siguiente:

\begin{verbatim}
auto eth0
iface eth0 inet dhcp
\end{verbatim}

El nombre de la interfaz (en este caso, {\tt eth0}) puede ser distinto, pero se
refiere a la interfaz de {\it ethernet} (por cable). Queremos cambiarlo para
establecer explícitamente una dirección IP estática que siempre lo va a
utilizar. Para esto cambiamos estas líneas para ser de la forma siguiente:

\begin{verbatim}
iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0
    gateway 192.168.1.1
\end{verbatim}

Esto hará que nuestro servidor tome la dirección IP {\tt 192.168.1.2} de forma
estática, y define el acceso a internet a través de la IP {\tt 192.168.1.1}
(Ésta es la dirección IP del {\it router}, se supone. Si en aquella red el {\it
router} tiene otra dirección, utilizar aquella).

\subsubsection{Configuración e Instalación del Servicio DNS}

Como mencionamos en un apartado anterior, para esta solución vamos a implementar
el servicio de resolución DNS Bind9 (también conocido como Named). Esto se tiene
que instalar en el servidor por medio del administrador de paquetes {\tt apt},
que instalará el paquete que precisamos además de todas sus dependencias:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{console}
# apt install bind9
\end{minted}

Como estamos utilizando un sistema basado en Debian, el servicio se inicializará
solo, con la configuración que viene por defecto.

Para la configuración de Bind9, nos interesa incluir desde nuestro archivo de
configuración un archivo que contendrá todos los dominios que nos interesan
bloquear. El archivo de configuración ha de ser como lo siguiente
(\cite{bind-sinkhole}):

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1.2
	]{text}
include "/etc/bind/blacklisted.zones";

zone "example.local" {
  type master;
  file "/etc/bind/zones/master/example.local.db";
};
\end{minted}

La línea que más nos interesa es la línea de {\tt include}. Esta línea incluye
el archivo que crearemos con todos los dominios que queremos bloquear.

En aquel archivo queremos tener una lista actualizada de todos los dominios en
la lista negra. Para esto haría falta crear un {\it script} capaz de actualizar
esta lista, haciendo lo siguiente:

\begin{enumerate}[i]
	\item Descargar la lista de internet.
	\item Manipular el contenido del fichero descargado para conformarse a lo
		que espera Bind9.
	\item Hacer una copia de respaldo del archivo que se encuentra allí
		actualmente.
	\item Instalarlo en su localización correspondiente.
	\item Reiniciar el servicio de DNS Bind9.
\end{enumerate}

El fichero de configuración de la lista negra ha de tener un dominio por cada
línea. El dominio de ha de definir de la forma siguiente
(\cite{bind-sinkhole}):

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1.2
	]{text}
zone "<dominio>" {type master; file "/etc/bind/zones/master/
blockeddomains.db";};
\end{minted}

Se hace notar que esta línea hace referencia a un archivo con nombre de
fichero {\tt blockeddomains.db}. Este fichero es el que redireccionará el
tráfico de nuestra red a la dirección IP de nuestro servidor. Su contenido sería
de la manera siguiente (\cite{bind-sinkhole}):

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1.2
	]{text}
;
; BIND data file for example.local
;$
$TTL    3600
@  IN  SOA   ns1.example.local. info.example.local. (
                 2014052101         ; Serial
                       7200         ; Refresh
                        120         ; Retry
                    2419200         ; Expire
                       3600)        ; Default TTL

       A     192.168.1.135
*  IN  A     192.168.1.135
       AAAA  ::1
*  IN  AAAA  ::1
\end{minted}

% TODO:
%  - Servidor Web
%  - Script PHP

\begin{figure}[h]
	\centering
	\includegraphics[width=0.75\textwidth]{imgs/router-dns.png}
	\caption{Ejemplo de configuración de DNS en un {\it router}.}
	\label{fig:router-dns}
\end{figure}

Una vez configurado el servicio DNS en nuestro servidor, podemos ya cambiar la
configuración DHCP de nuestra red para especificar el servidor DNS por defecto.
Para hacer esto, en el panel de control del {\it router} se puede encontrar esta
configuración en un apartado parecido al que se ve en la figura
\ref{fig:router-dns}. Simplemente se rellena con la dirección IP de nuestro
servidor en la red interna y ya debería de estar configurado como servidor DNS.

\subsubsection{Instalación y Configuración del Servicio HTTP}
\subsubsection{Instalación de la Página PHP}

\section{Conclusiones y Propuestas de Mejora}

\pagebreak

\printbibliography[
	heading=bibintoc,
	title={Bibliografía}
]

\pagebreak

\addcontentsline{toc}{section}{Derechos de Autor y Licencia}
\noindent
{\Large \bf Derechos de Autor y Licencia}

\noindent
Copyright \copyright\ \the\year\ Nicolás A. Ortega Froysa
<nicolas@ortegas.org> \\
\\
Este documento se distribuye bajo los términos y condiciones de la licencia
Creative Commons Attribution No Derivatives 4.0 International.

\end{document}