883 lines
36 KiB
TeX
883 lines
36 KiB
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}
|
|
|
|
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 de la manera siguiente:
|
|
|
|
\begin{table}[!h]
|
|
\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}
|
|
|
|
% TODO:
|
|
% - Rock64
|
|
% - SD card
|
|
% - +20% (security)
|
|
|
|
\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
|
|
]{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
|
|
]{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
|
|
]{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
|
|
]{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{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). 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{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 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
|
|
]{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
|
|
]{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}
|
|
|
|
Una vez creado el {\it script}, será de nuestro 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, podemos permitirnos actualizarla una vez
|
|
al mes. Para hacer esto, lo primero que hacemos es mover el {\it script} al
|
|
directorio {\tt /usr/local/bin} con permisos de ejecución (asumimos 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, podemos 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 nuestro {\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 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
|
|
]{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 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.
|
|
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 de nuestro 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, encontraremos, igual que con Bind9, que los
|
|
servicios de Nginx y PHP-FPM ya están en funcionamiento. Queremos 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 nos 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, esto nos interesa.
|
|
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, podemos 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 podemos verificar que funciona correctamente corriendo un
|
|
comando {\tt curl} sobre la IP de nuestro servidor. Si responde sin error un
|
|
código HTML entonces todo ha funcionado correctamente.
|
|
|
|
\subsubsection{Instalación de la Página PHP}
|
|
|
|
Nuestra página PHP no sólo precisa el uso de PHP, sino adicionalmente la
|
|
librería PHP denominada PHPMailer (como vimos 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 podemos encontrar los archivos correspondientes al código que nos
|
|
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, podemos seguir el tutorial de Mailtrap
|
|
(\cite{phpmailer-tutorial}) para nuestro {\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 nos 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 tengamos hecho el {\it script} de PHP, hemos de borrar el archivo
|
|
{\tt index.html} que viene por defecto en el directorio {\tt /var/www/html} para
|
|
que Nginx sepa utilizar nuestro archivo de 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}
|