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{fancyhdr}
\usepackage[
	backend=biber,
	style=apa,
	sorting=nyt,
	hyperref
]{biblatex}
\pagestyle{fancy}

\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. La
versión actual estable es Bullseye (11).

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

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}

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

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

\section{Pruebas y Despliegue}
\subsection{Plan de Pruebas}
\subsection{Manuales Técnicos y de Usuario}
\subsection{Plan de Despliegue}
\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}