TFC Xarxes Filtrado Web

José Antonio Placín

Consultor
David Carrera Pérez
   
 Esquema

● Objetivos
● Plan de trabajo
● Situación actual
● Protocolos
● Diseño
● Implementación
● Manual de la aplicación
● Bibliografía  
 
 Objetivos
● Crear una herramienta que permita al administrador del
sistema, controlar el uso que los usuarios de un equipo
hacen de internet.
– Restringir el acceso a dominios no deseables
– Bloquear páginas según su contenido
– Limitar el acceso a los puertos permitidos
– Registrar los intentos bloqueados

La programación se realizará en Java, con lo que será portable a 
cualquier sistema, cuyo único requisito será tener instalada una 
máquina virtual Java (JVM).

   
 Plan de Trabajo
Primer plazo: 2 semanas (del 3 al 16 de Octubre)

Descripción: Recogida de documentación y requisitos:

− Aplicaciones ya existentes que realicen labores semejantes.

− Información sobre protocolos implicados.
− Definición de la interface de usuario de la aplicación.
− Descripción de casos de uso.

Al final obtendremos:

− El día 14 de Octubre entregar el 1º informe de progreso quincenal.

− Descripción aplicaciones ya existentes.
− Guiones de casos de uso.
− Primeras inserciones en la memoria del proyecto.
− Ir adjuntando fuentes de información a la bibliografía.

Segundo plazo: 4 semanas (del 17 de Octubre al 14 de Noviembre)

Descripción: Análisis y especificación:

− Revisión de los casos de uso y especificación formal de los mismos.

− Identificación de las clases y sus relaciones.
− Definición de la interface de usuario de la aplicación.
− Estudio de la API de Java.
− Diseño de los casos de uso.
− Diseño de la persistencia ( ficheros de configuración y datos).
− Diseño de la interface de usuario.

Al final obtendremos:

− El dia 28 de Octubre entregar el 2º informe de progreso quincenal.

− El día 4 de Noviembre entrega de la 2ª PAC.
− Modelo del análisis.
− Continuación de la elaboración de la memoria del proyecto.
− Continuar adjuntando fuentes de información a la bibliografía.
   
 Plan de Trabajo

Tercer plazo: 5 semanas (del 15 de Noviembre al 18 de Diciembre)

Descripción: Implementación:

− Implementación del diseño realizado.

− Primeras pruebas de la aplicación.

Al final obtendremos:

− El 25/11 y el 9/12 entregar 3º y 4º informes de progreso

− El día 16 de Diciembre entrega de la 3ª PAC.
− Primer prototipo de la aplicación.
− Continuación de la elaboración de la memoria del proyecto.
− Continuar adjuntando fuentes de información a la bibliografía.

Cuarto plazo: 5 semanas (del 18 de Diciembre al 21 de Enero)

Descripción: Depuración y entrega:

− Implementación de la aplicación.
− Depuración de la aplicación.
− Creación de la presentación del TFC.

Al final obtendremos:

− El dia 6 de Enero entregar 5º informe de progreso.

− El día 16 de Diciembre entrega de la 3ª PAC.
− Aplicación.
− Memoria del TFC.
− Bibliografía.
− Manual de la aplicación.
− Presentación del TFC.
− El día 16 de Enero entrega de la memoria y aplicación.
− El día 21 de Enero presentación de la aplicación.

   
Situación actual

● Existen muchas aplicaciones de filtrado

● Con todo tipo de funcionalidades.
● No son multi-plataforma.
● Etiquetado ICRA:
– Sistema de auto-reglamentación.
– Protección de menores.
– Rápida determinación del tipo de contenidos.

   
Protocolo HTTP
HTTP Respuestas HTTP
● Protocolo de Transferencia de HiperTexto. ● Formato básico de una respuesta:

● Nivel de Aplicación. versión <SP> código <SP> descripción <CRLF>

● Actualmente HTTP/1.1 especificado en la RFC2610bis ● código: 3 dígitos que indican el resultado de la petición. Para
nuestra aplicación será imprescindible su reconocimiento, para
● Características: actuar en consecuencia. Los diferentes tipos:

– Arquitectura cliente-servidor
● 1xx – Respuesta de tipo informativo
● 2xx – Solicitud completada satisfactoriamente
– Sin estado
● 3xx – Redirección de la solicitud
– Localización universal (URI)
● 4xx – Error en la solicitud del cliente
– Datos (MIME)
● 5xx – Error del lado del servidor

Cabeceras HTTP
Peticiones HTTP ● Define la información que se intercambia.
● Formato de las peticiones:
● Sintaxis de una línea de cabecera:
método <SP> URI <SP> versión <CRLF>
– Nombre_del_campo: valor
● método – Utilizados por nuestra aplicación:
– En nuestro caso es importante al enviar peticiones establecer
● GET: Solicita el recurso especificado por el URI los siguientes campos:

● POST: Envía el recurso especificado por el URI

● Connection: close
– Así el servidor cierra la conexión tras enviar el
● URI – Identificador universal del recurso
mensaje.
● versión-Versión del protocolo HTTP que implementa el emisor de la ● Accept-Encoding ( lo eliminamos si existe)
petición.
  –  
Así el servidor no codifica el mensaje
(comprimir), pudiendo nuestra aplicación
filtrar el contenido.
Lenguaje HTML
HTML
● Lenguaje de HiperTexto de Marcas
● XHTML – Versión de HTML, más estricta
● Estructura de 3 secciones:
– Línea con información sobre la versión
del HTML que cumple el documento.
– Cabecera (head) de declaraciones con
definiciones del documento.
– Cuerpo (body) con el contenido del
documento.
– Estructuración y delimitación de
campos mediante “tags”:
<HEAD>
.........
<META HTTP­EQUIV=”pics­label” 
content=”etiquetas_ICRA”>
……..
</HEAD>
Formularios HTML
● Sección de un documento HTML, que
permite enviar información al remitente.
● La interface de esta aplicación está
implementada mediante diferentes
formularios. Tendremos que acceder a los
datos retornados estos.
● TAGS básicos:
– ACTION: Agente que procesará los datos
enviados.
– METHOD: Indica si será un método GET
o POST.
– NAME: Nombre del formulario.
– ENCTYPE: Tipo de codificación para el
envío.
Diseño
REQUISITOS Casos de usos
● Será programada en JAVA
● Al recibir una petición, primero aplicará el filtrado de 
puertos.
● Si es a un  puerto permitido, seguirá los siguientes 
pasos:
● Comprobará si el destino está en la lista de dominios 
registrados. Si está registrado puede estar prohibido o 
permitido. Si está prohibido denegará el servicio. Si 
está permitido no realizará filtrado alguno.
● Si el dominio no está registrado en la lista de dominios, 
comprobará si la URL contiene alguna palabra 
prohibida, y si no es así solicitará el recurso que le ha 
pedido la aplicación cliente y al recibirlo:
● Comprobará si tiene etiquetado ICRA, y si es así 
validará los códigos para determinar si esa página es 
accesible para el usuario de la aplicación.
● Si no tiene etiquetado ICRA habrá de comprobar el 
cuerpo del mensaje, para determinar si es o no accesible 
al usuario de la aplicación.
● Si se rechaza el recurso lo notificará a la aplicación 
cliente, y si se acepta se lo retransmitirá.
● Si el usuario es administrador, no se realiza filtrado de 
ningún tipo, ni se registra sus peticiones al web.
● Se registrarán todas las peticiones de los usuarios no 
administradores.
● Una vez realizado esto quedará de nuevo a la espera de 
otra solicitud.  
 
Diseño
DIAGRAMA  Casos de usos
ESTÁTICO DEL 
DISEÑO

   
Implementación
SOCKETS THREADS
Un socket es un punto final de un enlace de comunicación de dos vías,  Un Thread es un flujo secuencial dentro de un programa o proceso. No 
entre dos programas que se ejecutan normalmente a través de una red,  puede ejecutarse por sí mismo, sino siempre dentro de un proceso. La 
aunque también pueden correr en el mismo equipo. JVM permite a un proceso tener múltiples threads en ejecución 
Un socket queda completamente definido por una dirección IP, un  simultáneamente.
protocolo y un número de puerto.
SERVIDOR CLIENTE

Abrir canal Abrir canal
ServerSocket  s ServerSocket  s

Publicar en la red la
dirección del canal
s = new(puerto)

Espera solicitudes
while true

Espera peticiones Espera peticiones
s.accept() s.accept()

Crear thread
thread = s.accept()

Enviar y recibir datos Enviar y recibir datos
thread read() | write() thread read() | write()

  Cerrar canal comunicación Cerrar canal comunicación  
s.close() s.close()
Implementación
CLASES JAVA
ServerSocket:
Esta clase implementa el socket del lado del servidor. Una vez creado ha de permanecer a la escucha en el puerto especificado, que en esta aplicación será el 
8080, hasta que un cliente solicite conectarse con él. 
Creamos un objeto  con  la siguiente llamada al constructor:

socket = new ServerSocket(8080);

Socket:
Esta clase implementa la funcionalidad de los sockets. Es la que implementa el socket para el cliente. 
Creamos un objeto con la siguiente llamada al construtor:

Socket socket_cli = socket.accept();

Thread: 
La forma más directa para hacer un programa multi­thread es extender la clase Thread, y redefinir el método run(). Este método es invocado cuando se 
inicia el thread (mediante una llamada al método start() de la clase thread). El thread se inicia con la llamada al método run y termina cuando finaliza éste.
ThreadServidor nuevaPeticion=newThreadServidor(socket_cli,esAdmin,peticion);
//Arrancamos el nuevo hilo
nuevaPeticion.run();

DataInputStream:
Esta  clase proporciona los métodos necesarios para leer datos primitivos de un flujo de entrada. En nuestra aplicación será utilizada para leer los mensajes 
recibidos por el socket con el cliente.
       DataInputStream inCliente = new DataInputStream(socket_cli.getInputStream());

   
Implementación
CLASES JAVA
DataOutputStream:
Esta  clase proporciona los métodos necesarios para escribir datos primitivos en un flujo de salida. En nuestra aplicación será utilizada para enviar los 
mensajes por el socket hacia el servidor web.

DataOutputStream outWeb = new DataOutputStream(socketWeb.getOutputStream());

FileInputStream:
Esta clase nos proporciona los métodos necesario para la lectura de datos desde un fichero. La utilizamos para la lectura de los ficheros de configuración de 
la aplicación.

   fileIn = new FileInputStream(fitxer);
//Leemos el fichero entrado por parámetro
while((bytes = fileIn.read(buffer)) != ­1 ) 
//Y se lo enviamos al cliente
socket_cli.getOutputStream().write(buffer, 0, bytes);

FileOutputStream:
Esta clase nos proporciona los métodos necesario para la escritura de datos en un fichero. La utilizamos para escribir y crear los ficheros de configuración 
de la aplicación.

   FileOutputStream outFile = new FileOutputStream(fichero);
outFile.write((dominio.toString()+"\r\n").getBytes());

   
Implementación
PERSISTENCIA
Para la persistencia de los objetos creados o modificados durante las diferentes sesiones, se ha optado por guardar sus 
atributos en diferentes ficheros, convirtiendo cada objeto en una cadena de caracteres (String). 
Son los siguientes:

 listausuarios: Aquí guardaremos la información de los usuarios registrados. Cada string usuario tendrá 3 campos:
●

✗ nombre clave esAdministrador

 listapuertos:  Aquí guardaremos los puertos permitidos. Tendrá un sólo campo:
●

✗ numero_de_puerto

 listadominios: Aquí guardaremos los dominios registrados. Cada string  tendrá los siguientes campos:
●

✗ nombre estaPermitido

 listacodigos:  Aquí guardaremos los códigos ICRA. Cada string tendrá 3 campos separados por el carácter “­”:
●

✗ codigo­descripción­estaPermitido

 listapalabras: Aquí guardaremos las palabras prohibidas. Tendrá un sólo campo:
●

✗ palabra

 registro: Aquí guardaremos el registro de las peticiones realizadas por los usuarios. Cada string representa una 
●

petición, y tendrá los siguientes campos:  
 
✗ bloqueado puerto usuario dia hora duración recursoSolicitado
Implementación
DIAGRAMA DE 
CLASES

   
Implementación

Servidor

Solicita recurso
Cliente ServerSocket

No
Cliente solicita conexión

DIAGRAMA DE  Sí

FLUJO  Crear Petición

SIMPLIFICADO 
DE LA CLASE  Crear Thread al que se le envían como 
parámetros el socket con el cliente, y la 
Servidor petición.

   
Implementación

DIAGRAMA DE  ThreadServidorr

FLUJO 
SIMPLIFICADO  El puerto solicitado No
está permitido
DE LA CLASE  Sí
ThreadServidor No
El dominio solicitado
está registrado

Solicitar recurso al web Sí

No
El dominio está
Notificar denegación
prohibido
No
El recurso pasa No
el filtrado ICRA

Sí Solicitar recurso al web

Sí
Sí
El recurso pasa el
Enviar recurso al cliente FIN
filtrado de palabras

No

   
Manual de la aplicación
INSTALACIÓN MANUAL
Los archivos necesarios para la instalación, y funcionamiento de la  La interface de usuario se limita a la gestión de la configuración del filtrado 
aplicación son: que la aplicación realizará.
proxy.jar : Este archivo contiene todas las clases de la aplicación.  Esta gestión será llevada a cabo por los usuarios registrados como 
administradores por medio de cualquier navegador web. Para ello bastará 
con introducir en la barra de direcciones del navegador el nombre del 
Y Los documentos html que implementan la interface de configuración del  fichero del menú inicial “menuinicial.html” , y a partir de este menú acceder 
programa: a las diferentes opciones. 
 menuinicial.html También es posible acceder directamente a cualquiera de los ficheros de 
 administrarusuarios.html configuración, introduciendo su nombre en el navegador. 
 administrarpalabras.html Tal y como se especificó durante la fase de diseño,  el administrador podrá :
 administrardominios.html Añadir, borrar y modificar usuarios.
 administrarcodigos.html Añadir, borrar y modificar dominios registrados.
 administrarpuertos.html Añadir, borrar y modificar palabras prohibidas.
 administrarregistro.html Añadir, borrar y modificar códigos ICRA.
Consultar y borrar las peticiones registradas.
Para la ejecución del programa es suficiente copiar estos archivos en un 
mismo directorio, y desde éste ejecutar:    java -jar proxy.jar Los ficheros iniciales, sólo incorporan los mínimos elementos para la 
ejecución del programa, por ello, si se desea un buen filtrado se han de 
Las únicas restricciones son: ampliar estos ficheros, incorporando palabras y dominios.
El sistema ha tener instalada y configurada una JVM.
El usuario ha de tener permisos de lectura y escritura sobre este directorio.

   
Bibliografía

Freed, N. and N. Borenstein, 
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies , RFC 2045, November 
1996.

Berners­Lee, T., Fielding, R. and H. Frystyk, Hypertext Transfer Protocol ­­ HTTP/1.0 , RFC 1945, May 1996.

Palme, J., Common Internet Message Headers , RFC 2076, February 1997. [jg640]

Berners­Lee, T., Universal Resource Identifiers in WWW , RFC 1630, June 1994.

Berners­Lee, T., Masinter, L. and M. McCahill, Uniform Resource Locators (URL) , RFC 1738, December 1994.

Ignacio Díaz Asenjo, Universidad Carlos III de Madrid,  Hibernate: Persistencia de objetos en JAVA.

Enric Peig Olivé i Xavier Perramon Tornil, Universitat Oberta de Catalunya, Programació de Sockets.

José M. Barceló Ordina i Jordi Íñigo Griera, Universitat Oberta de Catalunya, 
TCP/IP Els protocols de la xarxa Internet.

Ramon Martí Escalé i Xavier Perramon Tornil, Universitat Oberta de Catalunya, Aplicacions de Internet.