TFC: apply revision
Signed-off-by: Nicolás Ortega Froysa <nicolas@ortegas.org>
This commit is contained in:
parent
31c3d3f9a6
commit
324f48cfa1
Binary file not shown.
@ -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 <<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>>).
|
||||
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 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}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user