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}

\fancyhead[LO]{}
\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}
\newcommand{\tabitem}{~~\llap{\textbullet}~}

\title{Sistema de Protección Parental: Angelus Custos}
\author{
	Alumno: Nicolás A. Ortega Froysa \\
	Tutor: Indalecio García Mateos \\
	Centro: Fundación San Pablo CEU 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
\listoffigures
\listoftables
\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 se optará, 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. Se hace sin ánimo de lucro, sólo
para proveer un servicio a la comunidad.

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

Actualmente el mundo está muy digitalizado, y los niños están expuestos a la
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 la 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 se explicó 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{Fases del Proyecto}

Siendo un proyecto de administración de redes, existen cuatro fases
fundamentales para seguir:

\begin{enumerate}[i.]
	\item Planificación de la solución: Hay que planear cómo solucionar el
		problema que se ha propuesto contando con la diferenciación de otras
		soluciones.
	\item Selección de {\it hardware} y {\it software}: Seleccionar los
		distintos componentes que servirán mejor los propósitos expuestos
		anteriormente.
	\item Implementación: Aplicar la solución, comprando el {\it hardware}
		necesario, instalándolo, y configurándolo.
	\item Mantenimiento: Cuando ya esté instalado y configurado, se tiene que
		mantener, actualizando y adaptándolo dependiendo de lo que vaya
		surgiendo.
\end{enumerate}

\subsection{Estimación de Costes}

\begin{table}[!ht]
	\centering
	\begin{tabular}{c|c}
		{\bf Producto} & {\bf Coste} \\ \hline
		Rock64-4GB & 40,82€ \\
		SD card 16GB & 5,29€ \\ \hline
		{\bf Total} & 46,11€ \\ \hline
		{\bf Total Prudente} & 55,34€
	\end{tabular}
	\caption{Presupuesto de {\it Angelus Custos} (\cite{pine64};
	\cite{sd-amazon})}
	\label{tbl:budget}
\end{table}

Este proyecto implica pocos gastos para su creación y mantenimiento, ya que en
cuestión de hardware sólo requiere la adquisición de un ordenador monoplaca, el
Rock64, y una tarjeta SD de 16GB. Dicho lo cual, los precios pueden fluctuar,
más aún en estos tiempos volátiles de logística complicada, por lo tanto es
prudente añadir, por precaución, un 20\% a la estimación de coste. Al final
saldría el presupuesto como en la tabla \ref{tbl:budget}.

\section{Desarrollo}
\subsection{Análisis de Requisitos}

Se puede dividir los requisitos del 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 los propósitos de este proyecto 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 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 se mencionaba 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 la 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}, existen algunos
ejemplos como los que se mencionaron 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 se compra. La diferencia principal viene a ser cuál
es el precio de cada placa respecto a las características que tiene. Entre las
opciones mencionadas, el Pine64 ya no está disponible, así que las opciones que
se pueden considerar serán el Rock64 y el Raspberry Pi.

En la tabla \ref{tbl:compare-boards} se puede ver una comparación entre dos
modelos similares, uno de Rock64 y otro de Raspberry Pi, comparando sólo
aquellas características que sean  de interés. Teniendo que elegir uno de éstos
para la solución, se ve 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
interesa, y son cosas que no merece la pena pagarlas si no se van a utilizar.
Por este motivo, el modelo que se utilizará será 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 se
mencionará 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 este 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:} La solución ha de ser algo que el administrador de
		la red puede instalar y luego mantener con 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 la 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 la 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 se propone es
		un servidor, específicamente un servidor de DNS con algunos mecanismos
		de filtrado. La distribución que se usa 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 las opciones se
limitarán solamente a 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 los criterios de este proyecto
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 proporciona
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, se continuará 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 la placa Rock64) y por lo
tanto es necesario seleccionar 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
disposición, como podrían ser PowerDNS, MaraDNS, NSD, KnotDNS, y Bind9.
Aquí hay una variedad muy amplia de opciones, y lo que se precisa para esta
solución es realmente muy sencillo. La única funcionalidad que 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 se seleccionará 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 hace falta tener un recurso que contenga una lista de páginas
prohibidas que se vaya actualizando, y que se pueda ir descargando y
actualizando de manera sistemática y frecuente. Esto es necesario ya que
siempre pueden haber nuevos dominios que se quieren bloquear, y no es posible
mantener una lista estática de este género. En esto se puede 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 son de interés 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 alguien quisiera instalar esta 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á el 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}).
Se escoge 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, se precisa un lenguaje de programación por el cual se podría 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 se utilizará 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 sirve utilizarlo
para esta solución, 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 habría 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 el 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}

La solución consiste en tener un servidor que sirve de {\em filtro} para todas
las peticiones DNS de la 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, se puede fijar en la figura \ref{fig:network-map},
que muestra una distribución básica de la red. El servicio DHCP de la red ha de
tener configurado a la dirección IP del 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 la red quiera acceder a un servidor por su
nombre de dominio (e.g.\ example.com) pedirá al 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, el servidor
devolvería su propia dirección IP para que así se conecte el cliente a el
{\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, se ha 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 el servidor
DHCP (normalmente en el propio {\it router}) para asignar la solución como
servidor DNS de la red. Para verificar esto se ha de conectar a la red por medio
de un ordenador ajeno y ver cuál es el servidor DNS que haya sido proporcionado.

Si la máquina de pruebas es también un sistema de Debian GNU/Linux, entonces se
puede asegurar que la información ha venido del servidor DHCP utilizando el
comando siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{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 se puede 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
	]{console}
# cat /etc/resolv.conf
nameserver 192.168.1.135
\end{minted}

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

Ahora, para asegurar de que se ha configurado correctamente el 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 se verifica cuál sería la respuesta si alguien de la
red quisiera acceder a una de las páginas prohibidas en la red. Debería de
devolver una respuesta de la forma siguiente, asumiendo que la dirección IP del
servidor es {\tt 192.168.1.135}:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{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í, se ha podido verificar el funcionamiento correcto de
la solución, y sin conectar siquiera a un servidor que provee el contenido
bloqueado.

\subsection{Manuales Técnicos y de Usuario}

Puede ser de gran utilidad hacer consultas la documentación oficial del {\it
software} propuesto.

Nginx tiene en su página web una documentación muy extensiva\footnotemark{} que
describe cómo configurarlo y las distintas directivas que existen.

\footnotetext{\url{http://nginx.org/en/docs/}}

Bind9 también tiene documentación en línea,\footnotemark{} pero puede ser más
accesible utilizar las páginas de manual que vienen en Debian. Se pueden
encontrar con el comando {\tt man named}.

\footnotetext{\url{https://bind9.readthedocs.io/en/latest/}}

\subsection{Plan de Despliegue}

Para desplegar la 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 el servidor, como se utiliza 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 se puede  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
	]{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 se puede insertar la tarjeta SD en el Rock64 y
empezar a configurar la red.

\subsubsection{Configuración de Red}

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

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1
	]{text}
auto eth0
iface eth0 inet dhcp
\end{minted}

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

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1
	]{text}
iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0
    gateway 192.168.1.1
\end{minted}

Esto hará que el 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 se mencionó en un apartado anterior, para esta solución se va 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 se precisa además de todas sus dependencias:

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

Como se está utilizando 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, interesa incluir desde el archivo de
configuración un archivo que contendrá todos los dominios que sean de interés
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
	]{text}
include "/etc/bind/blacklisted.zones";

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

La línea de más interés es la línea de {\tt include}. Esta línea incluye el
archivo que se creará más tarde con todos los dominios que se quieren bloquear.

En aquel archivo se quiere 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}

Una vez creado el {\it script}, será de interés correrlo de forma periódica.
Para esto lo más útil es un {\it cronjob}. Como es poco probable que se
actualice con frecuencia esta lista, se puede permitir actualizarla una vez al
mes. Para hacer esto, lo primero que se tiene que hacer es mover el {\it script}
al directorio {\tt /usr/local/bin} con permisos de ejecución (se asume que se
denomina {\tt update-blacklist.sh}):

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
# install -m 755 ./update-blacklist.sh /usr/local/bin
\end{minted}

Una vez instalado, se puede configurar el {\it crontjob} con el comando {\tt
crontab -e}, y en el archivo añadir una línea que sea de la manera siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
0 0 1 * *  /usr/local/bin/update-blacklist.sh
\end{minted}

Esta línea lo que hace es correr el {\it script} a la media noche (00:00) cada
día 1 de cualquier mes y cualquier día de la semana (estos últimos parámetros se
especifican utilizando el símbolo {\tt *}).

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
	]{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 la red a la dirección IP del servidor. Su contenido sería
de la manera siguiente (\cite{bind-sinkhole}):

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1
	]{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}

\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 el servidor, se puede ya cambiar la
configuración DHCP de la 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 del
servidor en la red interna y ya debería de estar configurado como servidor DNS.
Tan sólo es necesario reinicar el servicio de la forma siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
# systemctl restart bind9
\end{minted}

\subsubsection{Instalación y Configuración del Servicio HTTP}

La configuración del servicio HTTP requiere, en primer lugar, la
instalación del {\it software} requerido, siendo este Nginx, pero también
instalando los requisitos para que Nginx pueda tratar con {\it scripts} en PHP,
enviándolos a un CGI que lo interpretará con el intérprete de PHP:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
# apt install nginx php php-fpm
\end{minted}

Al instalar estos paquetes, se encontrará, igual que con Bind9, que los
servicios de Nginx y PHP-FPM ya están en funcionamiento. Hay que hacer una
modificación del archivo por defecto de configuración; el sitio {\it default}
que se encuentra en el fichero {\tt /etc/nginx/sites-available/default}. Este
archivo sirve generalmente como está escrito, ya que toda petición HTTP que
recibe el servidor lo interpretará esta configuración, y como tiene que
responder a cualquier petición a cualquier dominio bloqueado, funciona para las
intenciones propuestas. Sólo hay tres cosas importantes que cambiar:

\begin{enumerate}[i.]
	\item Eliminar la línea que contiene la directiva {\tt server\_name}.
	\item Añadir {\tt index.php} a la lista de archivos que utilizar por defecto
		en la directiva {\tt index}.
	\item Habilitar la gestión de páginas PHP por medio de PHP-FPM.
\end{enumerate}

El código de configuración para hacer lo segundo está ya dentro del archivo de
configuración {\tt default}, tan sólo hace falta descomentarlo. Al descomentar
ese bloque debería de parecer a lo siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		linenos,
		baselinestretch=1
	]{nginx}
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
\end{minted}

Una vez que esté bien configurado, se puede reiniciar el servicio con el
comando siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
# systemctl reload nginx
\end{minted}

Una vez configurado se puede verificar que funciona correctamente corriendo un
comando {\tt curl} sobre la IP del servidor. Si responde sin error un
código HTML entonces todo ha funcionado correctamente.

\subsubsection{Instalación de la Página PHP}

La página PHP no sólo precisa el uso de PHP, sino adicionalmente la librería PHP
denominada PHPMailer (como se ha visto en un apartado anterior). Para esto lo
primero necesario es instalar esta librería. Gracias a haber elegido una
librería que se encuentra en los repositorios de Debian, esto será tan fácil
como un comando de {\tt apt}:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{console}
# apt install libphp-phpmailer
\end{minted}

Al instalarse se puede encontrar los archivos correspondientes al código que
hará falta en un directorio de sistema:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		framesep=2mm,
		baselinestretch=1
	]{text}
/usr/share/php/libphp-phpmailer/src/
\end{minted}

Conociendo esta ruta, se puede seguir el tutorial de Mailtrap
(\cite{phpmailer-tutorial}) para el {\it script} de PHP. Haría falta
escribirlo en un archivo {\tt index.php} en el directorio {\tt /var/www/html}.
Se debería de configurar utilizando una cuenta y servicio SMTP ajeno.

Lo que más interesa en este {\it script} es escribir el contenido del correo, ya
que debería de contener la siguiente información importante:

\begin{itemize}
	\item Qué dispositivo ha intentado conectarse.
	\item A qué página bloqueada se ha intentado conectar.
	\item A qué hora ha ocurrido.
\end{itemize}

Para esto lo más simple sería que el contenido se escribiera de la manera
siguiente:

\begin{minted}[
		frame=lines,
		bgcolor=LightGray,
		linenos,
		framesep=2mm,
		baselinestretch=1
	]{php}
$mailbody = "Intento de acceso a página prohibida." .
  "Dispositivo: $_SERVER['REMOTE_ADDR']" .
  "Sitio bloqueado: $_SERVER['SERVER_NAME']" .
  "Fecha: " . date("l jS \of F Y h:i:s A");
\end{minted}

Una vez que se haya hecho el {\it script} de PHP, se ha de borrar el archivo
{\tt index.html} que viene por defecto en el directorio {\tt /var/www/html} para
que Nginx sepa utilizar el archivo de PHP.

\section{Conclusiones y Propuestas de Mejora}

Con esta implementación será posible implementar un {\it sinkhole} sencillo en
hogares domésticos para el uso personal. También permitirá la notificación de
los administradores de la red acerca de las conexiones que ocurran que no estén
permitidas. Se puede considerar, por tanto, una implementación básica y barata,
cumpliendo con las intenciones iniciales.

Sí que existen ciertas formas de evitar este filtro, como sería la conexión por
dirección IP. En un futuro se podría implementar, más que un simple servidor
DNS, un proxy entero que se encarga de mantener una lista de direcciones IP de
páginas prohibidas, y bloquear todas las conexiones a ellas. También existe la
posibilidad de que uno de los dispositivos utilice una herramienta para esquivar
estas restricciones, como sería una VPN o TOR.

Dicho esto, por lo general se ha de reconocer que nunca se podrá bloquear del
todo el acceso a ciertas páginas, a no ser que esto se haga de forma física
(poniendo presión a nuestros gobiernos a prohibir este tipo de servidores que
proveen contenidos malignos). Por lo tanto, lo esencial es minimizar las
posibilidades y la facilidad de acceso cuanto se pueda.

\begin{table}[ht!]
	\centering
	\begin{tabular}{|p{6cm}|p{6cm}|}
		\hline
		{\bf Debilidades} & {\bf Amenazas} \\ \hline \hline
		No cubre dispositivos fuera de la red &
		Siempre existirán nuevas páginas pornográficas \\
		\hline \hline
		{\bf Fortalezas} & {\bf Oportunidades} \\ \hline \hline
		Accesibilidad y coste &
		Bloquear páginas por IP \\
		\hline
	\end{tabular}
	\caption{Análisis DAFO.}
	\label{tbl:dafo}
\end{table}


\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}