https://doi.org/10.37815/rte.v34n3.955
Artículos originales
Análisis comparativo de Sistemas de Detección de
Intrusos (IDS) en entornos universitarios
Comparati=
ve
analysis of Intrusion Detection Systems (IDS) in university environments
Alex Caizapanta
González1 https://orcid.org/0000-0=
001-8112-7086
1
Enviado: 2022/07/03
Aceptado: 2022/09/16
Publicado: 2022/11/30
Resumen
En la actualidad, los diferentes ataques de tipo
cibernético han obligado a las organizaciones a buscar diversos equipos que=
las
protejan, sin embargo, los patrones de ataque no son iguales en todas las
organizaciones ya que su núcleo de trabajo no es el mismo. Por lo que, en e=
ste
trabajo se propone un análisis de los distintos patrones de ataque más
recurrentes en entornos universitarios, basándose en una comparativa de las
funcionalidades y resultados obtenidos mediante tres tipos de Sistemas de
Detección de Intrusos (IDS), dos de ellos utilizando software libre y el ot=
ro
licenciado, así también, efectuar ataques a los mismos en un entorno
controlado. Este artículo contiene los siguientes apartados: introducción, =
metodología
de trabajo, resultados – discusión y conclusiones. Con el análisis comparat=
ivo
se espera obtener estadísticas acerca de los patrones de ataque más crítico=
s a
los que se enfrenta este tipo de ambiente, para concluir se emiten las
directrices de configuraciones más óptimas para
mitigar dichos patrones de ataque.
=
Pa=
labras
clave: =
Ataque
cibernético, entorno controlado, patrones de ataque, software libre,
vulnerabilidad.
Abstract
Sumario: Introducción, Metodología de Trabajo, Resultados y Discusión y
Conclusiones. Como citar: Ca=
izapanta,
A. (2022). Análisis comparativo de Sistemas de Detección de Intrusos (=
IDS)
en entornos universitarios. Revista Tecnológica - Espol, 34(3), 118=
-138.
http://www.rte.espol.e=
du.ec/index.php/tecnologica/article/view/955
Nowadays, the different cyber-attacks have forced
organizations to find different equipment to protect them; however, the att=
ack
patterns are not the same in all organizations since their core work is not
identical. Therefore, this paper proposes an analysis of the most recurrent
attack patterns in university environments based on a comparison of the
functionalities and results obtained by three types of Intrusion Detection
Systems (IDS): two of them using free software and the third one using lice=
nsed
software, as well as to carry out attacks on them in a controlled environme=
nt.
This article contains the following sections: introduction, methodology,
results, discussion, and conclusions. With the comparative analysis, it is
expected to obtain statistics about the most critical attack patterns faced=
by
this type of environment. Finally, guidelines are issued for the most optim=
al
configurations to mitigate such attack patterns.
Introducción
En la actualidad todo tipo de organización posee infraestructura de
servidores y servicios que se hallan publicados en internet, por lo que, ex=
iste
innumerable información confidencial que se encuentra expuesta a potenciales
ataques cibernéticos. Debido a esto, en las organizaciones se deben tomar l=
as
respectivas medidas a nivel tecnológico y de gestión.
Una de las bases fundamentales en la protección del perímetro de una
infraestructura de red de una organización son los Sistemas de Detección de
Intrusiones IDS (por sus siglas en ingles), los cuales son sistemas encarga=
dos
de detectar y bloquear ataques cibernéticos mediante la ejecución de un
análisis de tráfico en la red y comparándolo con firmas de ataques conocido=
s o
comportamiento sospechoso. Por esta razón, en este trabajo se propone verif=
icar
cuáles son los patrones más comunes de ataques a infraestructuras de servid=
ores
y servicios en entornos universitarios utilizando tres IDS.
El interés de aplicar este análisis dentro de entornos universitario=
s se
debe a la diversidad de perfiles de usuarios de red existentes dentro de es=
tos
ambientes, ya que se pueden encontrar desde artistas, pasando por filósofos
hasta tener expertos en informática, donde cada perfil tiene sus propias
tendencias de navegación, aplicativos, software utilitario, entre otros. Ca=
da
una de estas tendencias puede traer riesgos detrás de dichas conexiones.
Por lo antes mencionado se debe tomar en cuenta que en las universid=
ades
tanto servidores como servicios ofrecidos están expuestos a ataques interno=
s y
externos a la infraestructura de red, principalmente debido a la diversidad=
de
dispositivos móviles de docentes, estudiantes y trabajadores.
La importancia de este proyecto se basa en proponer y validar
herramientas y configuraciones óptimas en las instituciones universitarias =
para
la prevención de ataques y la protección de las infraestructuras de red,
servidores y servicios críticos como los son las bases de datos, los sistem=
as
académicos, la información relacionada con investigaciones y publicaciones,
entre otros.
Para la ejecución del prototipo experimental en un entorno emulado se
toma como base la infraestructura de red, servicios y servidores de la
Universidad Central del Ecuador campus principal ubicado en la ciudad de Qu=
ito,
Ecuador. En este lugar, conviven diariamente un aproximado de 45000 personas
entre docentes, estudiantes y personal administrativo lo que proporciona una
gran variedad de dispositivos conectados a la red, la mayoría de ellos no
pertenecen a la institución y, por lo tanto, existe una alta probabilidad de
sufrir ataques a la infraestructura tecnológica.
Para la implementación del prototipo se ejecuta un análisis de la
topología de red existente en la Universidad, posteriormente se procede a la
revisión de los logs y patrones de ataque proporcionados por el módulo de I=
PS
del equipo de seguridad perimetral instalado en dicha institución. Con ello=
se
pretende reconocer a qué criterios se rigen estos patrones de ataques y a b=
ase
de esto examinar las reglas configuradas actualmente en el equipo antes
mencionado.
Para la aplicación del trabajo se tiene contemplado la ejecución de
pruebas de concepto con dos Sistemas de Detección de Intrusiones de Red (NI=
DS)
mediante software libre como lo son Snort y Sur=
icata
haciendo uso de un entorno emulado en laboratorio. En el momento que la
topología se encuentre implementada se ejecutarán diversas pruebas de evasi=
ón
de IDS utilizando herramientas basadas en la distribución Kali Linux con el
objeto de evaluar las soluciones antes mencionadas. Con cada una de estas
herramientas se realiza el respectivo análisis de los logs generados y los
patrones de ataque recolectados, para luego ser comparados con los resultad=
os
anteriormente obtenidos con el IDS existente en la infraestructura
universitaria. Con este procedimiento se mide la efectividad en la detecció=
n de
patrones de ataques y la respuesta de dichos sistemas a los mismos.
Finalmente, se ejecuta un análisis comparativo de los resultados
obtenidos para determinar las debilidades y fortalezas de cada sistema, a b=
ase
de esto se realiza las recomendaciones para mejorar las reglas del equipo en
producción, a fin de tener un patrón de configuración basado en las mejores
prácticas de implementación de este tipo de plataformas.
El objetivo ge=
neral de
la investigación es realizar un análisis exhaustivo de los distintos patron=
es
de ataque que se presentan en las universidades mediante la utilización de
sistemas de detección de intrusiones en software libre y licenciados. Con e=
stos
resultados, emitir recomendaciones para la configuración de reglas apropiad=
as
dentro de este tipo de entornos.
Los objetivos
específicos del proyecto son:
·
Anal=
izar
los patrones de ataques que se producen en la infraestructura de red, servi=
cios
y servidores en un entorno universitario mediante los logs registrados por =
el
IDS existente.
·
Esta=
blecer
un ambiente emulado para la ejecución de pruebas experimentales con los NID=
S de
software libre planteados.
·
Iden=
tificar
los tipos de patrones de ataques captados por los sistemas de detección de
intrusiones IDS experimentales previamente implementados en el entorno emul=
ado.
·
Comp=
arar
los resultados obtenidos en los diferentes sistemas probados y obtener
estadísticas acerca del comportamiento de los patrones de ataques en este t=
ipo
de entornos.
·
Esta=
blecer
un conjunto de buenas prácticas de configuración que optimice el funcionami=
ento
de los sistemas de detección de intrusiones IDS dentro de entornos
universitarios.
El artículo cuenta con tres secciones: metodología de trabajo,
resultados – discusión y conclusiones.
M
El presente tr=
abajo es
un proyecto basado en un prototipo experimental el cual se ha dividido en
diferentes fases para alcanzar los objetivos previamente planteados.
Como primera f=
ase se
realizó una revisión de la topología de red perteneciente a la Universidad
Central del Ecuador donde se identificó cada uno de sus equipos, segmentos =
de
red, servidores y seguridad perimetral. Específicamente se identificó dentro
del equipo de seguridad perimetral dónde se encuentra y cómo funciona el mó=
dulo
IDS del mismo, se obtuvo los logs generados por este módulo en un determina=
do
periodo de tiempo para ser analizados de manera exhaustiva y así determinar=
los
patrones de ataque que afectan a la infraestructura universitaria y
clasificarlos en una escala cuantitativa.
Como segunda f=
ase y
basados en el análisis de la infraestructura existente en la institución, se
implementó el piloto experimental en un entorno emulado, dividido en dos
etapas. En la primera etapa se utilizó Snort, e=
l cual
es un IDS open source que funciona en modo de N=
IDS,
el mismo que obtuvo un conjunto de logs con patrones de ataque evaluados en=
un
periodo de tiempo determinado. La segunda etapa es la ejecución del mismo
conjunto de pruebas pero utilizando Suricata como
NIDS, obteniendo un nuevo conjunto de logs en su análisis. Estos resultados
serán utilizados para ejecutar un estudio de la efectividad en respuesta de
detección de amenazas de las tres plataformas puestas en prueba. Para esta =
fase
se realizaron ataques controlados para efectuar un análisis de vulnerabilid=
ades
en el entorno antes mencionado, en la ejecución de los ataques programados =
se
utilizaron herramientas que forman parte de la distribución Kali Linux.
En la tercera =
fase se
realizó el análisis comparativo del comportamiento de los IDS antes descrit=
os,
destacando el nivel de detección de ataques en cada uno de ellos. Con estos
resultados se emiten buenas prácticas de configuración para la implementaci=
ón
de NIDS en instituciones universitarias las cuales constan en este artículo=
.
El diseño de la
investigación es experimental, transversal, cuantitativa, de laboratorio y
correlacional.
Este proyecto =
es
experimental debido a que el investigador incluye en su estudio una compara=
tiva
de los IDS en Entornos Universitarios, en el cual la variable independiente=
de
estudio fue manipulada, ya que, se emularon varias pruebas de concepto para
validar la eficiencia en la detección de amenazas por parte de IDS basados =
en
software libre.
Experimento: S=
ituación
de control en la cual se manipulan, de manera intencional, una o más variab=
les
independientes (causas) para analizar las consecuencias de tal manipulación
sobre una o más variables dependientes (efectos)
Es transversal=
debido
a que la recolección de datos se da en tiempo establecido, en este caso, el
proyecto se empezó a ejecutar con datos obtenidos de enero a junio de 2020,
como lo señala
Como lo mencio=
na
Fue en un cont=
exto de
laboratorio al controlar con mayor rigurosidad el ambiente reducido. Inicia=
lmente
estaba prevista que sea de campo al ser aplicada en la UCE; pero, a causa d=
e la
pandemia de Covid-19, se debió emular el entorno, como lo menciona
Es correlacion=
al de acuerdo a lo señalado por
Resultados y Dis= cusión
Análisis de la Topología de Red Existente
En la red de la UCE conviven aproximadame=
nte
45000 personas entre estudiantes, docentes y personal administrativo, quien=
es
utilizan recursos de red, servicios y ancho de banda, por lo que, también
resulta un escenario atractivo para un atacante debido a la variedad de
conexiones entrantes y salientes desde esta infraestructura.
Como se puede observar en la Figura 1 la
topología de red de la institución posee un esquema de conexión redundante
hacia dos proveedores de servicio. En el borde de la red se encuentran dos
equipos de seguridad perimetral de la marca Check
Point. Vale recalcar que en esta sección se ha hecho una división de la red=
en
dos partes ya que uno de los equipos de seguridad perimetral protege la
conectividad hacia las instalaciones de facultades, mientras que, el otro
dispositivo se encarga de la protección del segmento de servidores.
Figura 1=
Topología de red - Universidad Central del Ecuador
Fuente: Dirección de Tecnologías de la Información=
y Comunicaciones
(DTIC)
Los mencionados equipos de seguridad peri=
metral
son UTM
Análisis de Tráfico y Conexiones Concurrentes en la Institución
En la actualidad, la UCE tiene un contrat=
o de
servicio de internet con una capacidad de 3 Gbps de Ancho de Banda, el cual=
es
distribuido entre los segmentos de red de facultades, servidores y sedes a
nivel nacional. Se debe destacar que la mayoría de consumo de tráfico y
conexiones concurrentes se presentan en el campus principal de la Ciudadela
Universitaria; sin embargo, por cuestiones relacionadas con la pandemia de =
la
Covid-19 -la cual llevó a un confinamiento a nivel mundial- en aquellos
momentos gran parte de esa carga fue trasladada al segmento de servidores p=
or
lo que los usuarios accedían a los servicios en línea de la institución.
A continuación, se listan los datos obten=
idos
de la infraestructura universitaria desde el 19 de enero hasta el 19 de jun=
io
de 2020:
· =
Pico=
más
alto de tráfico: 2,2 Gbps el 24 de enero de 2020.
· =
Apro=
ximadamente
11300 conexiones concurrentes diarias.
· =
Pico=
más
alto de tráfico en la red (Periodo confinamiento): 868 Mbps el 20 de mayo de
2020.
· = En t= odo el periodo del análisis realizado se obtuvieron 27200 logs del módulo de IPS.<= o:p>
·
Aproximadamente un 80=
% de
las conexiones a esta red se las hace desde dispositivos móviles personales
conectados de manera inalámbrica.
Análisis Estadístico de los Eventos de Seguridad Logs Proporcionados por los Equipos= de Seguridad Perimetral
En esta sección se realiza un análisis del
comportamiento de las amenazas de seguridad en entornos universitarios medi=
ante
el estudio de los logs tomados del módulo de IDS/IPS de los equipos de
seguridad perimetral pertenecientes a la UCE, la DTIC[6] ha
permitido la toma de muestras de enero a junio de 2020, las mismas que fuer=
on clasificadas
por su severidad, su recurrencia y los servicios que pueden afectar.
Figura 2=
Referencia CPAI de la Vulnerabilidad Inyección de Comandos sobre = Payload HTTP
Fuente:
Check Point Software Technologies Ltd
En la fase previa del análisis se logró
observar que el equipo de la marca Check Point de la instit=
ución
clasifica los eventos detectados por el IDS/IPS mediante unas referencias
llamadas CPAI (Check Point Advisories),
las cuales manejan la codificación mostrada en la Figura 2.
Las vulnerabilidades descritas en este tr=
abajo
hacen referencia al catálogo administrado por el MITRE[7]
llamado CVE
En el siguiente apartado se muestra uno d=
e los
análisis realizados mediante los gráficos estadísticos obtenidos en febrero=
de
2020: En los cuales se establece los tipos de ataques más frecuentes de for=
ma
mensual, teniendo como criterio que los mismos superen un 10% del volumen de
datos capturados.
Análisis de Logs Correspondientes al Mes =
de
febrero de 2020
Se recolectaron un total de 16214 eventos,
siendo el mes en el que se han registrado la mayor cantidad de ellos.
En la Figura 3,
constan los ataques más frecuentes detectados por el módulo de IDS del equi=
po
de seguridad perimetral. Se reportan los siguientes resultados: en primer
lugar, se ubica la Inyección de Comandos sobre Payload=
HTTP con el 32%, en segundo lugar, Escáner de Seguridad ZMap
a través de HTTP con el 15%, seguido de Ejecución Remota de Código de MVPower DVR y Escáner de Seguridad SIPVicious
con el 13%.
Figura 3=
Ataques detectados en el mes de febrero de 2020
Fuente: DTIC – UCE
En la Figura 4, se
evidencia un análisis estadístico tomando en cuenta la severidad de los ata=
ques
detectados por el dispositivo, de los cuales se ha obtenido que el 69% de l=
os
ataques son críticos, mientras que el 30% son de severidad alta y el 1% med=
ia.
<= o:p>
Figura 4=
Severidad de ataques detectados en el mes de febrero de 2020
Fuente:
DTIC – UCE
En la Figura 5, se
verifica que los ataques detectados en febrero de 2020 están dirigidos a la
afectación de los siguientes servicios: en primer lugar, se tiene http con =
el
49%; en segundo lugar, https con el 14%; seguido por SIP con el 11%, y para
finalizar se tiene la categoría de otros con el 11%.
Figura 5=
Servicios afectados por ataques en el mes de febrero de 2020
Fuente:
DTIC – UCE
Interpretación de Resultados
En esta sección es importante señalar que=
el
análisis previo a la ejecución del piloto experimental contiene en total tr=
ece
gráficos estadísticos debido a que se ha realizado un promedio de tres tipo=
s de
mediciones entre los meses de enero y junio de 2020.
De los cinco gráficos que corresponden a =
los
principales tipos de ataques captados por el IDS del equipo de seguridad
perimetral se evidencia que los eventos más frecuentes son:
· =
En p=
rimer
lugar, se encuentra Inyección de Comandos sobre Payloa=
d
HTTP (Vulnerabilidad 1) el cual posee un número de referencia de Check Point CPAI-2018-0567, categori=
zado
como “Violación de Servidor Aplicaciones Web”, considerado como una
vulnerabilidad con severidad crítica. La misma que afecta a la carga útil de
http, en el cual el atacante envía solicitudes diseñadas para las víctimas.=
Si
dicha explotación es exitosa el atacante puede ejecutar código arbitrario e=
n el
ordenador de la víctima
· =
En s=
egundo
lugar (Vulnerabilidad 2), se tiene Escáner de Seguridad ZMap
a través de HTTP, catalogado por Check Point co=
mo un
ataque de tipo “Violación Mediante Escáner de Aplicaciones”, código
CPAI-2016-0215 de severidad alta. Éste es considerado un potencial atacante=
que
puede utilizar herramientas de escaneo de vulnerabilidades como ZMap[10] para
detectar brechas de seguridad en servidores de la o las víctimas
· =
El E=
scáner
de Seguridad SIPVicious (Vulnerabilidad 3),
considerado de severidad alta, clasificado por Check
Point como “Violación Mediante Escáner de Aplicaciones”, código CPAI-2016-0255
· =
Ejec=
ución
Remota de Código de MVPower DVR (Vulnerabilidad=
4) se
encuentra en cuarto lugar, como una severidad crítica, identificada por
· =
En quinto lugar, con el código CPAI-2019-0083 de Check
Point se encuentra NoneCMS ThinkPHP
Ejecución Remota de Código (Vulnerabilidad 5), de severidad crítica =
· =
En s=
exto
lugar, se tiene a Inyección de Comandos a Draytek
Vigor (Vulnerabilidad 6), identificado por=
Check Point como “Vio=
lación
de Protección de Servidores de Aplicaciones”, código CPAI-2020-0320 de
severidad crítica, está enfocada en equipos de la marca Draytek Vigor y consiste en la ejecución de códi=
go
malicioso de manera remota por parte de un atacante
· =
Por
último, en este análisis se tiene a Escáner de Puertos Masscan
(Vulnerabilidad 7), código CPAI-2015-0259, de sever=
idad
alta, catalogado como “Violación Mediante Escáner de Aplicacione=
s”
Los servicios que reportaron mayor afecta=
ción
son http, https y SIP, los mismos que están directamente relacionados con l=
as
vulnerabilidades descritas con anterioridad y que se encuentran debidamente
referenciados.
En abril y mayo se evidencia la categoría=
de
“otros” en la cual están incluidos varios puertos y servicios, tanto TCP co=
mo
UDP, la cual ocupa el primer lugar en las estadísticas y de los cuales se ha
identificado las siguientes vulnerabilidades:
· =
En p=
rimer
lugar, se encuentra Ejecución Remota de Comandos e Inyección de Objetos en
Joomla (Vulnerabilidad 8), clasificada como “Violación de Servidor Aplicaciones Web”, código CPAI-2015-1401
· =
En segundo lugar, Técnicas de Evasión en
Inyección SQL (Vulnerabilidad 9),
identificada mediante código CPAI-2014-1565, de severidad crítica y clasifi=
cada
como “Inteligencia de Aplicaciones”, permite al atacante ejecutar comandos =
SQL
en servidores remotos obteniendo información confidencial, ejecutar código
malicioso, modificar bases de datos, entre otros
· =
DoS<=
/span>[11] por
Inundación de Red en Servidores Web Memcached
(Vulnerabilidad 10), se encuentra en tercer lugar, identificada con el códi=
go CPAI-2018-0154, el cual también hace referencia al CVE-2018-100011=
5,
de severidad alta y clasificada como “Violación de Servidor Aplicaciones We=
b”
· =
En cuarto lugar, Ejecución Remota de Comandos en Apache Struts (Vulnerabilidad 11), identificada como “Violaci=
ón de
Protección del Servidor Apache”, código CPAI-2015-0737 de severidad alta, h=
ace
referencia al CVE-2013-2251
· =
El siguiente en la lista es DoS para Equipos Cisco (Vulnerabilidad
12), el cual tiene una severidad alta, con código CPAI-2018-1038, catalogado
como “Violación de Protección de Servidores de Aplicaciones” =
· =
En sexto lugar, Divulgación de Información de OpenSSL/TLS/DTLS
Pruebas Comparativas de Sistemas de Detección de Intrusiones de Red (NIDS) utilizan= do Snort y Suricata en un Entorno Emulado<= /p>
En este apartado se describe la topología= de red y las pruebas experimentales ejecutadas con los NIDS de código abierto = Snort y Suricata. Basándose en el análisis realizado = en las secciones anteriores se ha considerado importante emular el segmento red co= rrespondiente a los servidores de la universidad, ya que al momento de realizar la investigación dicho segmento soportaba todas las conexiones que los usuarios establecían para consumir los servicios proporcionados por la institución.<= o:p>
En la topología mostrada en la Figura 6, se
pueden diferenciar la capa de borde representada por un router
Cisco 881, el cual cumple con las funciones de firewall, como capa de core se ha utilizado un switch Cisco 3560. Al mismo se
conectan todos los servidores de pruebas que tienen publicados diferentes
servicios. De manera adicional se ha ubicado un ordenador que hace las
funciones de NIDS y que tiene virtualizados tanto Snor=
t
como Suricata, los mismos que están destinados a obtener los datos producid=
os
por los ataques que van a ser ejecutados desde el exterior de la red.
Figura 6=
Diagrama Topol=
ógico
del Prototipo Experimental Emulado
Implementació=
n de Snort como
NIDS
Snort es una
de las aplicaciones open source más conocidas p=
or su
efectividad en el análisis de tráfico, debido a la gran cantidad de firmas =
que
posee. Además, en la actualidad, está avalada por la empresa Cisco destacad=
a en
el ámbito de las redes a nivel mundial.
=
Para la
implementación de Snort como NIDS se ha tomado =
como
base la distribución CentOs 7 Minimal,
en la cual se han instalado todos los paquetes requeridos y se han seguido =
los
procedimientos de configuración proporcionados en la sección “Documents” de la página web de S=
nort
www.snort.org/documen=
ts.
Implementació=
n de
Suricata como NIDS
Suricata es otra aplicación open source la cual puede ser utilizada como IDS, la misma=
que
ha sido escogida para este piloto experimental debido a sus prestaciones y =
el
óptimo manejo de reglas el cual es parecido a las utilizadas por Snort. Sin embargo, y como se pudo determinar en el e=
stado
del arte realizado al inicio de este proyecto Suricata tiene como ventaja la
utilización de varios procesadores del servidor, en el cual se encuentre
instalado lo que lo hace más efectivo al momento de realizar el análisis de
tráfico, en especial cuando se habla de grandes infraestructuras de red.
De manera análoga a lo explicado en la se=
cción
anterior, para la instalación y puesta en marcha de Suricata como NIDS se h=
an
seguido las guías de configuración presentes en la página web de este
aplicativo
Análisis Comparativo Basado en los NIDS <=
span
class=3DSpellE>Snort y Suricata
A continuación, como muestra se presenta =
una de
las PoC
Vulnerabilidad 11: Ejecución Remota de Comandos en Apache Struts
Como se explica en el análisis previo a e=
sta
prueba, la vulnerabilidad permite inyección de código en el lenguaje OGNL q=
ue
utiliza Apache. Para comprobar si Snort detecta=
este
tipo de ataques se plantea un escenario donde una máquina virtual con Metasploitable 2 es la víctima, la cual será el objet=
ivo de
un atacante que utiliza Metasploit framework de Kali Linux para explotar esta vulnerabil=
idad.
En la Figura 7 se indica que dentro de la herramienta ya mencionada se encuentra el exploit “Apache Struts 2 Namespa= ce Redirect OGNL Injection” con el cual se procede a ejecutar el ataque hacia el ordenador vulnerable.<= o:p>
Figura 7=
Ataque Apache Struts 2 Namespace Redirect OGNL Injection
La Figura 8
muestra que al momento de realizar la comprobación mediante la consola del =
NIDS
Snort se puede verificar que se han generado tr=
es
tipos de logs relacionados con esta vulnerabilidad.
Figura 8=
Alertas en la consola de Snort para el ataque Apache St= ruts 2
De las alertas obtenidas se pueden difere=
nciar
dos que pertenecen a la categoría “SERVER-APACHE RULES” la primera con Sid<=
/span>[14]
1-47690 mediante la cual se notifica al momento que un atacante intenta acc=
eder
a la clase java.lang.ProcessBuilder con el obje=
to de
obtener privilegios de administrador. La segunda tiene el identificador Sid
1-39191, el cual notifica intentos de ejecución de código remoto enfocado en
versiones de Apache Struts 2.3.20.X. El tercer log mostrado con Sid 1-1201,=
se
genera al momento que un servidor responde con un estado “403 Forbidden” y pertenece a la categoría “INDICATOR-COMP=
ROMISE
RULES”
De manera adicional se ha verificado en la
página web de Snort que existen otras reglas
relacionadas a este tipo de vulnerabilidad la mismas que pertenecen a la
categoría “SERVER-APACHE RULES” (Sid 1-27243, Sid 1-27244, Sid 1-27245, Sid
1-29747, Sid 1-29748 y Sid 1-49885)
Por otro lado, se procedió a revisar los
eventos registrados por el IDS Suricata. Se comprobó de la existencia de cu=
atro
reglas relacionadas con esta amenaza. La primera es “ET EXPLOIT Apache Stru=
ts
Posible OGNL Java ProcessBuilder URI” la misma =
que se
describe como un intento de escalada de privilegios el identificador de
Las Figuras Figura 9 y Figura 10
muestran el contenido de los archivos fast.log y eve.j=
son
respectivamente.
Figura 9=
Contenido del archivo fast.log para la vulnerabilidad de Apache Struts 2
Figura 10
<= span lang=3DES-US>Tráfico almacenado en el archivo eve.json= de Suricata para la vulnerabilidad de Apache Struts 2
Análisis Comparativo de las Soluciones de=
IDS Check Point, Snort y Suri=
cata
En el Tabla 1 se
evidencia el análisis comparativo de las plataformas en software libre vers=
us
la de software licenciado evaluadas en este trabajo de investigación. Esta
tabla cuanticualitativa está compuesta por el
conjunto de vulnerabilidades previamente analizados, una sección de evaluac=
ión
de cumplimiento de la prueba experimental, una explicación técnica basada en
las pruebas experimentales y al final el porcentaje de vulnerabilidades
detectas por cada una de las soluciones.
Tabla 1=
Análisis Comparativo de IDS Evaluados
|
VULNERAB=
ILIDAD |
IDS
CHECKPOINT (UCE) |
IDS SNOR=
T |
IDS SURI=
CATA |
|||
|
DETECCIÓ=
N |
ANÁLISIS=
|
DETECCIÓ=
N |
ANÁLISIS=
|
DETECCIÓ=
N |
ANÁLISIS=
|
|
|
1 |
X |
Identificado como una
vulnerabilidad que afecta a aplicaciones en entornos Web. |
|
No detecta el agente =
de
ataque, solo detectar intentos de emitir solicitudes HTTP utilizando una
dirección IP en particular. |
X |
Identifica que es un
ataque de inyección de comandos sobre una aplicación web, de manera adici=
onal
identifica el agente de ataque. |
|
2 |
X |
Detecta al software <=
span
class=3DSpellE>Zmap como el origen del ataque de escaneo de puerto=
s en
la infraestructura de red. |
X |
A pesar de no detecta=
r el
agente malicioso de manera específica si detecta los intentos de escaneo =
en
los puertos donde se efectuó los ataques. |
|
No captó los ataques
efectuados por este tipo de software. |
|
3 |
X |
Señala al software |
X |
Detecta de manera
efectiva al software Sipvicius como origen del
ataque. |
X |
Detecta de manera
efectiva al software Sipvicius como origen del
ataque . |
|
4 |
X |
Señala la afectación =
de
equipos de la marca MVPower debido a ejecución
remota de comandos. |
X |
Detecta efectivamente=
la
vulnerabilidad en dispositivos MVPower. |
X |
Detecta efectivamente=
la
vulnerabilidad en dispositivos MVPower. |
|
5 |
X |
Reconocido por una
vulnerabilidad que permite ejecución remota de código. |
X |
Se ha detectado de ma=
nera
efectiva esta vulnerabilidad. |
|
No soporta este tipo =
de
vulnerabilidad, no se encontró referencias en el conjunto de reglas. |
|
6 |
X |
Señala la afectación =
de
equipos de la marca Draytek debido a ejecución
remota de comandos. |
X |
Existen varias reglas=
que
soportan este tipo de vulnerabilidad. |
|
No soporta este tipo =
de
vulnerabilidad, no se encontró referencias en el conjunto de reglas
instaladas. |
|
7 |
X |
Identifica a MASSCAN =
como
agente de ataque mediante la ejecución de escaneo de puertos. |
|
No reconoce al softwa=
re MASSCAN
como origen del ataque, solo muestra logs genéricos. |
|
No reconoce al softwa=
re
MASSCAN como origen del ataque, solo muestra logs genéricos. |
|
8 |
X |
Ataque de inyección de
objetos PHP a varias versiones de Joomla. |
X |
Si reconoce el tipo d=
e vulnerabilidad
referido a Joomla. |
|
No soporta este tipo =
de
vulnerabilidad, no se encontró referencias en el conjunto de reglas
instaladas. |
|
9 |
X |
Detecta técnicas
relacionadas con la inyección de comandos en SQL Server. |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataques. |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataques. |
|
10 |
X |
Detecta ataques de |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataques. |
X |
Existe una sola regla
enfocada en este tipo de ataque. |
|
11 |
X |
Detecta ejecución de
código malicioso en el lenguaje ONGL que utiliza Apache Struts. |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataque. |
X |
Existe una amplia var=
iedad
de reglas que detectan este tipo de ataque. |
|
12 |
X |
Detecta DoS a equipos
Cisco. |
X |
Existe un conjunto de
reglas genéricas que detectan este tipo de ataque. |
|
Detecta de manera par=
cial
este tipo de ataque. |
|
13 |
X |
Detecta brechas de
seguridad en Open SSL TLS DTLS con paquetes de tipo =
Heartbeat. |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataque. |
X |
Existe una amplia
variedad de reglas que detectan este tipo de ataque. |
|
Total de Vulnerabilidades detectadas |
13 |
|
10 |
|
7 |
|
|
Porcentaje de Vulnerabilidades detectadas |
100% |
|
77% |
|
54% |
|
Mientras que la Tabla 2 resume
un conjunto de ventajas y desventajas proporcionadas por estas plataformas =
que
fueron evaluadas en distintos ámbitos de acorde a los resultados obtenidos =
en
las pruebas experimentales.
Tabla 2=
Ventajas y Desventajas de las Plataformas Evaluadas
|
COMPARAT=
IVO
DE VENTAJAS Y DESVENTAJAS |
|||
|
CRITERIO=
S |
CHECKPOI=
NT
(UCE) |
SNORT |
SURICATA=
|
|
Actualización de regl=
as |
Las actualizaciones se
pueden configurar para que se ejecuten de manera automática. La marca pos=
ee
una nube propia donde se encuentran todo tipo de actualizaciones y bases =
de
datos de ataques de día cero; sin embargo, esto depende si tiene el
licenciamiento activado. Como desventaja dicho licenciamiento tiende a ser
costoso. La marca ha creado una comunidad de usuarios para reportar amena=
zas
o falsos positivos llamada CheckMates. No per=
mite
la creación de reglas propias. |
Posee una gran base de
datos de firmas para actualizar el IDS. Se puede programar actualizaciones
manuales o automáticas con diversas herramientas. Por ejemplo, oinkmaster, que posee soporte de Talos que es una g=
ran
nube con bases de datos de reglas, se puede tener nivel de suscripción, p=
or ejemplo,
una cuenta gratuita actualiza sus bases de datos cada 30 días, mientras q=
ue
una suscripción pagada puede recibirlas diariamente. Los costos con
accesibles en comparación con Checkpoint. De =
manera
adicional puede soportar las community rules =
proporcionadas
por EmergingThreasts. Se pueden configurar re=
glas
de manera manual. |
La actualización de l=
as
firmas del IDS se las ejecuta desde el sitio Web de =
EmergingThreasts,
lo cual potencializa a esta plataforma ya que las reglas nativas de la mi=
sma
son limitadas, se puede programar actualizaciones automáticas mediante
herramientas como oinkmaster. Una desventaja =
es que
no se pueden cargar otro tipo de firmas por lo que lo hace limitado. Se
pueden configurar reglas de manera manual. Ampliamente apoyado por comuni=
dades
de software libre. |
|
Referencias CVE |
Cada una de las regla=
s de
la marca poseen su respectiva referencia con la lista de vulnerabilidades=
de
CVE lo que hace más fácil la identificación de una amenaza. |
La mayoría de las reg=
las
buscadas en la página Web de Snort se referen=
cia a
la lista de vulnerabilidades de CVE. |
Se debe buscar en la
página de EmergingThreasts, el tipo de
vulnerabilidad para verificar la existencia de una regla, no siempre se p=
uede
encontrar la referencia CVE. |
|
Información proporcio=
nada
por los logs |
Las reglas presentan
alertas en la interfaz gráfica de la plataforma las cuales tienen informa=
ción
completa de la vulnerabilidad detectada. |
Las alertas visualiza=
das
en la consola del equipo entregan información básica de la vulnerabilidad
encontrada, para complementar esa información se debe buscar en la página=
Web
de Snort. |
Suricata registra las
alertas de vulnerabilidad en dos archivos, eve.json<=
/span>
que entrega información bastante detallada sobre el flujo de tráfico
detectado, protocolo, clasificación, entre otros, mientras que en el arch=
ivo
fast.log se registra el evento con un formato similar al presentado por <=
span
class=3DSpellE>Snort. |
|
Capacidad de detecció=
n |
Alta capacidad de
detección, gracias a la actualización de vulnerabilidades de día cero que
maneja la marca. |
En el estudio realiza=
do
se determinó que tiene una buena capacidad de detección de amenazas, toma=
ndo
en cuenta que las pruebas se las ejecutó con una cuenta de suscripción
gratuita. |
La capacidad de detec=
ción
es buena, pero depende de la cantidad de firmas que tenga el IDS y de la
actualización de estas, resulta a veces laborioso la búsqueda de este tip=
o de
reglas. |
|
Facilidad de uso |
Posee interfaz gráfic=
a lo
que proporciona un manejo más intuito del módulo de IDS. Sin embargo, si =
se
exige de un manejo de datos avanzado se requiere un conocimiento a nivel =
de
experto en la marca ya que la consola de comandos maneja comandos propiet=
arios. |
Los comandos de ejecu=
ción
no son complejos, por lo que resulta fácil el acceso a la herramienta y la
lectura de logs, los mismos que se presentan en tiempo real en la consola=
del
equipo. Se puede integrar una interfaz gráfica como complemento de Snort. |
Los comandos de ejecu=
ción
no son complejos, por lo que resulta fácil el acceso a la herramienta, las
alertas se almacenan en tiempo real en dos archivos sin necesidad de
configuración previa lo que resulta una ventaja al momento de extraer esos
datos para un posterior estudio. Se puede integrar una interfaz gráfica c=
omo
complemento de Suricata. |
|
Integración con otras
funcionalidades |
Al ser un equipo
propietario la mayor parte de funcionalidades deben ser de la marca y que
contengan el licenciamiento respectivo, lo que incrementa el costo de la
solución. |
Fácil integración con
otras funcionalidades, como manejo de entorno gráfico, bases de datos,
geolocalización, entre otras, lo que no conlleva costos extras en la
implementación. |
Fácil integración con
otras funcionalidades, como manejo de entorno gráfico, bases de datos,
geolocalización, entre otras, lo que no conlleva costos extras en la
implementación. |
Mejores Prácticas de Configuración de IDS=
A base del análisis comparativo realizado=
en la
sección anterior se ha podido establecer un conjunto de buenas prácticas de
configuración de reglas de IDS las cuales están dirigidas a la optimización=
del
funcionamiento de estas plataformas en entornos universitarios:
· =
Al m=
omento
de la implementación de un sistema de detección de intrusiones es fundament=
al
establecer una fase inicial destinada a la recopilación y análisis de
vulnerabilidades. En esta fase en la que el dispositivo se encuentra en mod=
o de
escucha se pueden detectar los tipos de ataques más recurrentes, clasificar=
los
en una escala dependiendo de su riesgo y ejecutar un plan de acción para la
configuración de las reglas de IDS basándose en los patrones previamente
captados. Con eso se logra una implementación acorde a las necesidades de la
institución.
· =
Es
importante que dentro de los análisis realizados se puedan buscar patrones =
de
comportamiento de tráfico legítimo como, por ejemplo, servicios publicados =
por
la institución que no requieran estar siendo monitorizados y se puedan crear
excepciones a las reglas sobre dicho tráfico. Con esto se logra ahorrar en
recursos de procesamiento del servidor donde se tenga instalada la solución=
.
· =
Es
importante tener conocimiento de cómo realizar un contacto con la empresa u
organismo propietario de la solución con el objeto de poder reportar tráfico
anómalo, falsos positivos, brechas de seguridad en las reglas, entre otros.
Como, por ejemplo, en el caso de Check Point se=
debe
notificar al centro de soporte de usuarios, Snort
puede reportarlo en su página web y Suricata puede remitir esta información=
en
la página web de EmergingThreasts.
· =
Nunc=
a se
debe dejar de lado el procedimiento de actualización no solo de las bases de
datos de firmas que tienen este tipo de plataformas, sino también se debe a=
ctualizar
y parchar de manera adecuada el sistema operativo donde se encuentre
funcionando el IDS, como un ejemplo de esto.
Snort y Suricata se actualizan por medio=
de la
herramienta oinkmaster, así también, se debe
actualizar debidamente el sistema operativo CentOS 7 que es la base de este
prototipo experimental.
· =
A pe=
sar de
tener un conjunto de configuraciones funcional y firmas debidamente
actualizadas es indispensable que en cualquier infraestructura de red se
realicen análisis de tráfico de manera periódica, con el objeto de revisar =
los
eventos generados y con esto poder prevenir o descartar potenciales nuevas
amenazas.
· =
A ba=
se de
los trabajos ejecutados en este piloto experimental se recomienda como una
buena práctica en la implementación de este tipo de entornos realizar copia=
s de
seguridad del IDS que tenga la configuración más estable, antes de ejecutar
cualquier cambio en el sistema operativo, su aplicativo o sus reglas, este
contingente se vuelve fundamental en el caso de recuperación de fallos.
· =
Es
indispensable en especial en un entorno de tipo universitario no solo
monitorear el tráfico externo a la red, sino también el tráfico de la LAN ya
que en este tipo de ambientes existe una gran cantidad de equipos que no pu=
eden
ser controlados ya que los mismos son de uso personal como es el caso de
Smartphone, laptops, entre otros.
· =
Es
importante realizar una revisión y clasificar las reglas que se encuentren
descargadas en el dispositivo, con el objeto de deshabilitar cualquiera de
ellas que no tenga nada que ver con el tráfico monitorizado. Por ejemplo, e=
n un
entorno universitario no se tiene tráfico de tipo industrial, por lo que, se
puede deshabilitar reglas referidas a Scada, Mo=
dbus,
etc., este procedimiento permite optimizar los recursos de procesamiento del
servidor.
· =
El
rendimiento del equipo donde se encuentre instalada una de estas plataformas
depende de la complejidad de las reglas configuradas y la cantidad de tráfi=
co
que atraviese la misma, ya que en muchos casos cuando el dispositivo inspec=
ciona
una gran cantidad de paquetes dicho rendimiento baja o empieza a descartar
algunos de ellos.
· =
Es
importante verificar si cada una de estas plataformas tienen la funcionalid=
ad
de IPS, ya que luego de verificar la red y registrar todo tipo de comportam=
iento
sea este anómalo o no, se deben configurar las reglas necesarias para poner=
a
la plataforma de seguridad en modo de Prevención.
Tomando como referencia las buenas prácti=
cas
aquí descritas se ha procedido a la aplicación de éstas en el módulo de IPS=
del
equipo Check Point perteneciente a la UCE. Los
procedimientos realizados se los ejecutaron en conjunto con el personal de
Infraestructura que es parte de la DTIC.
En este trabaj=
o se
concluyó que mediante un análisis de los logs generados por los IDS propues=
tos
en el piloto experimental se puede obtener información relevante acerca del
comportamiento de determinados tipos de ataques a los que se enfrentan los
entornos universitarios. En particular a identificar diferentes tipos de
tráfico, sus orígenes, el tipo de contenido de los paquetes, y como estos s=
on
evidenciados por plataformas basadas en software libre. De esta manera
determinar el grado de efectividad de este tipo de IDS al enfrentarse a
entornos reales.
Se comprobó que
implementando un piloto experimental se puede establecer un entorno de prue=
bas
de concepto completo en el cual se configuran un conjunto de dispositivos l=
os
mismos que puedan emular un entorno real. En este caso en particular, se
estableció una infraestructura tecnológica que permitía tener servicios
publicados al exterior de la red, atacantes externos y los NIDS los cuales
permiten analizar toda esa interacción de la red experimental con el exteri=
or.
Esto proporciona un ambiente de pruebas controlado el cual no pone en riesgo
información crítica de usuarios, equipos y servicios pertenecientes a los
entornos universitarios.
Con el conjunt=
o de
ataques ejecutado en este trabajo de investigación se logró determinar la
efectividad de los sistemas de detección de intrusiones basados en software
libre, previamente implementados, al momento de identificar diferentes tipo=
s de
patrones de ataques, los cuales se obtuvieron de un análisis previo de amen=
azas
captadas en un entorno universitario real.
Con el análisis
comparativo efectuado se verificó las fortalezas y debilidades de cada uno =
de
los IDS puestos a prueba. Los cuales fueron evaluados de acuerdo con la
capacidad de detección del conjunto de vulnerabilidades emuladas en
laboratorio, con esta comparativa se obtuvo el porcentaje de efectividad de=
los mismos. Por lo que, a base de estos parámetros val=
orados
también se logró determinar un conjunto de ventajas y desventajas de cada u=
na
de estas soluciones.
Luego del estu=
dio
realizado se logró establecer un conjunto de buenas prácticas de configurac=
ión
las cuales son una base para la implementación de cualquier tipo de platafo=
rmas
de sistemas de detección de intrusiones en general. Estas prácticas permiten
optimizar el funcionamiento de estos dispositivos, ahorrar recursos en
procesamiento y clasificar de manera adecuada los eventos reportados por el
IDS.
Se determinó m=
ediante
un análisis exhaustivo los tipos de patrones de ataque más recurrentes en un
entorno universitario evaluados en un determinado periodo de tiempo basado =
en
las pruebas experimentales ejecutadas y una efectiva valoración de estas al
realizar el análisis comparativo.
Finalmente es =
importante
acotar que dentro de este estudio existió una limitante circunstancial, ya =
que,
al encontrarse en pleno periodo de pandemia se hizo complicado la
implementación de los IDS experimentales directamente en la infraestructura=
de
la institución ya que no se contaban con los permisos de acceso requeridos.=
Por
ello, se considera una opción viable a futuro implementar estos dispositivo=
s de
manera presencial, así también, este proyecto sienta un precedente para la
ejecución de trabajos futuros en los que se pueda analizar nuevos patrones =
de
ataque especialmente utilizando técnicas de análisis de anomalías de tráfico
enfocadas en este tipo de instituciones. De esta manera potenciar la detecc=
ión
de malware de día cero.
Reconocimientos
Este trabajo f=
orma
parte de la Tesis “Análisis y Pruebas Comparativas de Sistemas de Detección=
de
Intrusos (IDS) en Entornos Universitarios” en la Universidad Internacional =
de
La Rioja. El autor desea expresar su agradecimiento a la Dirección de
Tecnologías de la Información y Comunicaciones (DTIC) de la Universidad Cen=
tral
del Ecuador y en particular a su Director el Ing. Cesar Morales Mejía, MEd. por la colaboración en este trabajo de investiga=
ción.
Refe=
rencias
Check Point Softwa= re Technologies LTD. (2020, Julio 16). Check Point Advisories. https://www.checkpoint.com/advisories/<= o:p>
Hernánd=
ez,
R., Fernández, C., & Baptista, P. (2010). Metodología de la
Investigación. Mexico: The Mc Graw-Hill.
=
KALI
ORG. (2020, Julio 16). KALI TOOLS. SIPVicious Package Description:
https://tools.kali.org/sniffingspoofing/sipvicious
NIST. (2020, Abril=
14). National
Vulnerability Database. https://nvd.nist.gov/vuln
OWASP. =
(2020,
Julio 16). OWASP COMMUNITY. Obtenido de
https://owasp.org/www-community/attacks/
Snort. (2020, Sept=
iembre
21). snort.org. SNORT:
https://snort.org/
VULNERS.COM. (2020=
, Julio
2). VULNERS.COM. https://vu=
lners.com/nessus/AOST_NVR_SHELL.NASL
[1]=
UCE:
Universidad Central del Ecuador
[2]=
Unif=
ied
Threat Management o Gestión Unificada de Amenazas
[3]=
Network Address Translation
[4]=
Virtual Private Network
[5]=
LAN
(Local Area Network): Red de Área Local
[6] DTIC:
Dirección de Tecnologías de la Información y Comunicaciones
[7]=
MITRE: Organización sin ánimo de lucro perteneciente a los Estados Unid=
os
de América.
[8]=
CVE:
Common Vulnerabilities and Exposures, es un catálogo de vulnerabilidades. <=
/span>
[9]=
OWAS=
P: Open Web Application Security Project que es un proyecto enf=
ocado
a la seguridad de aplicaciones Web.
[10]
ZMap: Proyecto de código abierto que permite realizar estudios de host y
servicios publicados en Internet.
[11] DoS:
Denial-of-service attack, ataque de Denegación de Servicios.
[12]
OGNL: Object-Graph Navigation Language, Lenguaje de Expresiones de códi=
go
abierto utilizados en Java.
[13]
PoC
(Proof of Concept): Prueba de Concepto
[14]
Sid:
Snort identifier (Identificador de la categoría de una regla).