Para un software de vigilancia automática de seguridad informática se está desarrollando un componente encargado de validar las direcciones IP en varios miles de listas negras (de host maliciosos) conocidas, y reportar aquellas que existan en al menos cinco de dichas listas.
Dicho componente está diseñado de acuerdo con el siguiente diagrama, donde:
-
HostBlackListsDataSourceFacade es una clase que ofrece una 'fachada' para realizar consultas en cualquiera de las N listas negras registradas (método 'isInBlacklistServer'), y que permite también hacer un reporte a una base de datos local de cuando una dirección IP se considera peligrosa. Esta clase NO ES MODIFICABLE, pero se sabe que es 'Thread-Safe'.
-
HostBlackListsValidator es una clase que ofrece el método 'checkHost', el cual, a través de la clase 'HostBlackListDataSourceFacade', valida en cada una de las listas negras un host determinado. En dicho método está considerada la política de que al encontrarse un HOST en al menos cinco listas negras, el mismo será registrado como 'no confiable', o como 'confiable' en caso contrario. Adicionalmente, retornará la lista de los números de las 'listas negras' en donde se encontró registrado el HOST.
Al usarse el módulo, la evidencia de que se hizo el registro como 'confiable' o 'no confiable' se dá por lo mensajes de LOGs:
INFO: HOST 205.24.34.55 Reported as trustworthy
INFO: HOST 205.24.34.55 Reported as NOT trustworthy
Al programa de prueba provisto (Main), le toma sólo algunos segundos análizar y reportar la dirección provista (200.24.34.55), ya que la misma está registrada más de cinco veces en los primeros servidores, por lo que no requiere recorrerlos todos. Sin embargo, hacer la búsqueda en casos donde NO hay reportes, o donde los mismos están dispersos en las miles de listas negras, toma bastante tiempo.
- Haga que el método checkHost paralelize la búsqueda dentro de las N listas negras, teniendo en cuenta:
-
Considerando las características del hardware (número de núcleos), se quiere manejar exactamente 8 hilos de procesamiento.
-
Cuando la búsqueda en paralelo consiga la evidencia de las 5 ocurrencias en las listas negras, NO se deberían hacer más búsquedas.
-
La nueva versión (paralelizada) NO debe tener posibles condiciones de carrera.
-
El comportamiento global se debe conservar. Es decir, al final se DEBE reportar el host como confiable o no confiable, y mostrar el listado con los números de las listas negras respectivas.
-
Dentro del método checkHost Se debe mantener el LOG que informa, antes de retornar el resultado, el número de listas negras revisadas VS. el número de listas negras total (línea 60). Se debe garantizar que dicha información sea verídica bajo el nuevo esquema de procesamiento en paralelo planteado.
-
Se sabe que el HOST 202.24.34.55 está reportado en listas negras de una forma más dispersa, y que el host 212.24.24.55 NO está en ninguna lista negra.
Siga al pie de la letra estas indicaciones para la entrega de este punto. Hacer la entrega en un formato que NO SEA .ZIP, o sin la estructura abajo indicada, penalizará la nota en 0.5.
-
Limpie el proyecto
$ mvn clean
-
Configure su usuario de GIT
$ git config --global user.name "Juan Perez" $ git config --global user.email juan.perez@escuelaing.edu.co -
Desde el directorio raíz (donde está este archivo README.md), haga commit de lo realizado.
$ git add . $ git commit -m "entrega parcial - Juan Perez"
-
Desde este mismo directorio, comprima todo con: (no olvide el punto al final en la segunda instrucción)
$ zip -r APELLIDO.NOMBRE.zip . -
Abra el archivo ZIP creado, y rectifique que contenga lo desarrollado (incluyendo la carpeta .git).
-
Suba el archivo antes creado (APELLIDO.NOMBRE.zip) en el espacio de moodle correspondiente.
-
IMPORTANTE!. Conserve una copia de la carpeta y del archivo .ZIP.