556 lines
26 KiB
TeX
556 lines
26 KiB
TeX
\documentclass[11pt,a4paper,titlepage]{article}
|
|
\usepackage[spanish,es-tabla]{babel}
|
|
\usepackage{csquotes}
|
|
\usepackage{hyperref}
|
|
\usepackage{graphicx}
|
|
\usepackage{subcaption}
|
|
\usepackage{minted}
|
|
\usepackage{enumerate}
|
|
\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. 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}{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}{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}{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}{console}
|
|
# unxz Armbian_<version>_Rock64_<codename>_current_<version>.img.xz
|
|
# dd if=Armbian_<version>_Rock64_<codename>_current_<version>.img \
|
|
of=/dev/mmcblk1 bs=1M
|
|
\end{minted}
|
|
|
|
Al acabar este paso ya podemos insertar la tarjeta SD en nuestro Rock64 y
|
|
empezar a configurar la red.
|
|
|
|
\subsubsection{Configuración de Red}
|
|
|
|
Cuando hayamos inicializado nuestro servidor y estemos dentro, lo primero que
|
|
queremos hacer es configurar la red para utilizar una dirección estática. Esto
|
|
se hace manipulando el fichero {\tt /etc/network/interfaces}. Ahí nos aparecerá
|
|
algo parecido a lo siguiente:
|
|
|
|
\begin{verbatim}
|
|
auto eth0
|
|
iface eth0 inet dhcp
|
|
\end{verbatim}
|
|
|
|
El nombre de la interfaz (en este caso, {\tt eth0}) puede ser distinto, pero se
|
|
refiere a la interfaz de {\it ethernet} (por cable). Queremos cambiarlo para
|
|
establecer explícitamente una dirección IP estática que siempre lo va a
|
|
utilizar. Para esto cambiamos estas líneas para ser de la forma siguiente:
|
|
|
|
\begin{verbatim}
|
|
iface eth0 inet static
|
|
address 192.168.1.2
|
|
netmask 255.255.255.0
|
|
gateway 192.168.1.1
|
|
\end{verbatim}
|
|
|
|
Esto hará que nuestro servidor tome la dirección IP {\tt 192.168.1.2} de forma
|
|
estática, y define el acceso a internet a través de la IP {\tt 192.168.1.1}
|
|
(Ésta es la dirección IP del {\it router}, se supone. Si en aquella red el {\it
|
|
router} tiene otra dirección, utilizar aquella).
|
|
|
|
\subsubsection{Configuración e Instalación del Servicio DNS}
|
|
|
|
% TODO:
|
|
% - Servidor DNS
|
|
% - Servidor Web
|
|
% - Script PHP
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=0.75\textwidth]{imgs/router-dns.png}
|
|
\caption{Ejemplo de configuración de DNS en un {\it router}.}
|
|
\label{fig:router-dns}
|
|
\end{figure}
|
|
|
|
Una vez configurado el servicio DNS en nuestro servidor, podemos ya cambiar la
|
|
configuración DHCP de nuestra red para especificar el servidor DNS por defecto.
|
|
Para hacer esto, en el panel de control del {\it router} se puede encontrar esta
|
|
configuración en un apartado parecido al que se ve en la figura
|
|
\ref{fig:router-dns}. Simplemente se rellena con la dirección IP de nuestro
|
|
servidor en la red interna y ya debería de estar configurado como servidor DNS.
|
|
|
|
\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}
|