diff --git a/TFC/tfc-naortega.pdf b/TFC/tfc-naortega.pdf index 43b5569..f36ecff 100644 Binary files a/TFC/tfc-naortega.pdf and b/TFC/tfc-naortega.pdf differ diff --git a/TFC/tfc-naortega.tex b/TFC/tfc-naortega.tex index 610e089..4236a87 100644 --- a/TFC/tfc-naortega.tex +++ b/TFC/tfc-naortega.tex @@ -20,6 +20,7 @@ \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} @@ -32,7 +33,7 @@ \author{ Alumno: Nicolás A. Ortega Froysa \\ Tutor: Indalecio García Mateos \\ - Centro: CEU San Pablo Andalucía \\ + Centro: Fundación San Pablo CEU Andalucía \\ Ciclo: Administración de Sistemas Informáticos en Red } @@ -45,6 +46,8 @@ \maketitle \tableofcontents +\listoffigures +\listoftables \pagebreak \section{Introducción} @@ -56,14 +59,14 @@ 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 +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} -Vivimos en un mundo muy digitalizado donde los niños están expuestos a +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 @@ -82,9 +85,9 @@ adicción a la pornografía, un amigo o familiar que se responsabiliza. Muchos d 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. +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 @@ -97,7 +100,7 @@ el mundo de hoy. \subsection{Justificación} -Como explicamos anteriormente, es necesario una solución para protegernos -- a +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 @@ -114,9 +117,9 @@ 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 @@ -140,16 +143,11 @@ saldría el presupuesto de la manera siguiente: \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}. +Se puede dividir los requisitos del proyecto en dos categorías principales: {\it +hardware} y {\it software}. \subsubsection{Requisitos Hardware} @@ -171,19 +169,20 @@ 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. +{\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 nos conviene utilizar un +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 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. +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 @@ -199,41 +198,40 @@ luego simplemente insertarlo en su lugar en la placa e iniciar el ordenador. \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. +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} podemos ver una comparación entre dos +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 nos interesan. Teniendo que elegir uno de éstos -para nuestra solución, vemos que el {\it RPi 4 Model B} proporciona una mejora +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} +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}. +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 -mencionaremos después. Se puede utilizar este guía para montar la solución con +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 nuestro caso, los criterios para la selección de una distribución son los +En este caso, los criterios para la selección de una distribución son los siguientes: \begin{itemize} @@ -242,10 +240,10 @@ siguientes: 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 + 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 nuestra solución se + \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 @@ -253,23 +251,23 @@ siguientes: 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 + 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 proponemos es + \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 usemos ha de ser conocida por ser + 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 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 +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: @@ -282,17 +280,18 @@ Entre las distribuciones de Linux, los que más se destacan son los siguientes: \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. +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 @@ -300,40 +299,40 @@ 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}. +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 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 <>, <>, <>, y -<>, además de otras categorías que podrían ser de interés al -usuario (e.g.\ <>). +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 <>, <>, +<>, y <>, además de otras categorías que +podrían ser de interés al usuario (e.g.\ <>). 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 +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á nuestro servidor HTTP local, tanto Nginx como Apache podrán +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}). -Escogeremos a Nginx simplemente por el criterio de mayor conocimiento y +Se escoge a Nginx simplemente por el criterio de mayor conocimiento y experiencia con su uso y administración. \begin{figure}[h] @@ -344,27 +343,27 @@ experiencia con su uso y administración. \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 +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 utilizaremos será PHP. +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 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 +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}) @@ -379,7 +378,7 @@ actualizar, sobre todo el proceso de una actualización automática. \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 +todas las peticiones DNS de la red local. Generalmente se puede dividir en dos partes esenciales: \begin{itemize} @@ -390,20 +389,20 @@ dos partes esenciales: 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. +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 nuestra red quiera acceder a un servidor por su -nombre de dominio (e.g.\ example.com) pedirá a nuestro servidor la resolución de +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, nuestro servidor -devolvería su propia dirección IP para que así se conecte el cliente a nuestro +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. @@ -411,18 +410,18 @@ 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 +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 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. +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 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: +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, @@ -446,9 +445,10 @@ 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 +Luego se puede verificar cuál es la dirección IP del servidor DNS configurado mirando el archivo {\tt /etc/resolv.conf}: \begin{minted}[ @@ -461,16 +461,16 @@ mirando el archivo {\tt /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. +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 asegurarnos de que se ha configurado correctamente nuestro servidor +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 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}: +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, @@ -487,15 +487,15 @@ 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. +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} \subsection{Plan de Despliegue} -Para desplegar nuestra solución haría falta seguir los siguientes pasos: +Para desplegar la solución haría falta seguir los siguientes pasos: \begin{enumerate}[i.] \item Instalar el sistema operativo (Armbian). @@ -507,10 +507,10 @@ Para desplegar nuestra solución haría falta seguir los siguientes pasos: \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 +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}: @@ -527,15 +527,15 @@ de la tarjeta SD corresponde al fichero especial {\tt /dev/mmcblk1}: of=/dev/mmcblk1 bs=1M \end{minted} -Al acabar este paso ya podemos insertar la tarjeta SD en nuestro Rock64 y +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 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: +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, @@ -549,9 +549,9 @@ 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 +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 cambiamos estas líneas para ser de la forma siguiente: +utilizar. Para esto se cambian estas líneas para ser de la forma siguiente: \begin{minted}[ frame=lines, @@ -566,17 +566,17 @@ iface eth0 inet static gateway 192.168.1.1 \end{minted} -Esto hará que nuestro servidor tome la dirección IP {\tt 192.168.1.2} de forma +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 mencionamos en un apartado anterior, para esta solución vamos a implementar +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 precisamos además de todas sus dependencias: +que instalará el paquete que se precisa además de todas sus dependencias: \begin{minted}[ frame=lines, @@ -587,11 +587,11 @@ que instalará el paquete que precisamos además de todas sus dependencias: # 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. +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, nos interesa incluir desde nuestro archivo de -configuración un archivo que contendrá todos los dominios que nos interesan +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}): @@ -610,10 +610,10 @@ zone "example.local" { }; \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. +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 queremos tener una lista actualizada de todos los dominios en +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: @@ -627,11 +627,11 @@ esta lista, haciendo lo siguiente: \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 +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}[ @@ -643,7 +643,7 @@ denomina {\tt update-blacklist.sh}): # install -m 755 ./update-blacklist.sh /usr/local/bin \end{minted} -Una vez instalado, podemos configurar el {\it crontjob} con el comando {\tt +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}[ @@ -655,9 +655,9 @@ crontab -e}, y en el archivo añadir una línea que sea de la manera siguiente: 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 *}). +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 @@ -675,7 +675,7 @@ blockeddomains.db";}; 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 +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}[ @@ -709,11 +709,11 @@ $TTL 3600 \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. +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 de nuestro +\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: @@ -728,7 +728,7 @@ Tan sólo es necesario reinicar el servicio de la forma siguiente: \subsubsection{Instalación y Configuración del Servicio HTTP} -La configuración de nuestro servicio HTTP requiere, en primer lugar, la +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: @@ -742,14 +742,14 @@ enviándolos a un CGI que lo interpretará con el intérprete de PHP: # 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 +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 nos sirve generalmente como está escrito, ya que toda petición HTTP que +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, esto nos interesa. -Sólo hay tres cosas importantes que cambiar: +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}. @@ -777,8 +777,8 @@ location ~ \.php$ { } \end{minted} -Una vez que esté bien configurado, podemos reiniciar el servicio con el comando -siguiente: +Una vez que esté bien configurado, se puede reiniciar el servicio con el +comando siguiente: \begin{minted}[ frame=lines, @@ -789,17 +789,17 @@ siguiente: # 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 +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 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}: +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, @@ -810,7 +810,7 @@ como un comando de {\tt apt}: # apt install libphp-phpmailer \end{minted} -Al instalarse podemos encontrar los archivos correspondientes al código que nos +Al instalarse se puede encontrar los archivos correspondientes al código que hará falta en un directorio de sistema: \begin{minted}[ @@ -822,13 +822,13 @@ hará falta en un directorio de sistema: /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 +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 nos interesa en este {\it script} es escribir el contenido del -correo, ya que debería de contener la siguiente información importante: +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. @@ -853,9 +853,9 @@ $mailbody = "Intento de acceso a página prohibida." . "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 +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 nuestro archivo de PHP. +que Nginx sepa utilizar el archivo de PHP. \section{Conclusiones y Propuestas de Mejora}