914 lines
37 KiB
TeX
914 lines
37 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}
|
|
|
|
\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}
|
|
|
|
\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.
|
|
|
|
\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}
|
|
|
|
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}.
|
|
|
|
\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}
|
|
|
|
\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:} Nuestra 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}
|
|
|
|
Nuestra 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 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}
|
|
|
|
Nuestra 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}
|
|
|
|
\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}
|