maltrail
0.76
Maltrail es un sistema de detección de tráfico malicioso que utiliza listas (negras) disponibles públicamente que contienen rastros maliciosos y/o generalmente sospechosos, junto con rastros estáticos compilados a partir de varios informes AV y listas personalizadas definidas por el usuario, donde el rastro puede ser cualquier cosa, desde un nombre de dominio (por ejemplo, zvpprsensinaix.com para malware Banjori), URL (p. ej. hXXp://109.162.38.120/harsh02.exe para ejecutable malicioso conocido), dirección IP (p. ej. 185.130.5.231 para un atacante conocido) o el valor del encabezado HTTP User-Agent (por ejemplo, sqlmap para inyección automática de SQL y herramienta de toma de control de bases de datos). Además, utiliza mecanismos heurísticos avanzados (opcionales) que pueden ayudar a descubrir amenazas desconocidas (por ejemplo, nuevo malware).
Se están utilizando las siguientes listas (negras) (es decir, feeds):
360bigviktor, 360chinad, 360conficker, 360cryptolocker, 360gameover,
360locky, 360necurs, 360suppobox, 360tofsee, 360virut, abuseipdb, alienvault,
atmos, badips, bitcoinnodes, blackbook, blocklist, botscout,
bruteforceblocker, ciarmy, cobaltstrike, cruzit, cybercrimetracker,
dataplane, dshieldip, emergingthreatsbot, emergingthreatscip,
emergingthreatsdns, feodotrackerip, gpfcomics, greensnow, ipnoise,
kriskinteldns, kriskintelip, malc0de, malwaredomainlistdns, malwaredomains,
maxmind, minerchk, myip, openphish, palevotracker, policeman, pony,
proxylists, proxyrss, proxyspy, ransomwaretrackerdns, ransomwaretrackerip,
ransomwaretrackerurl, riproxies, rutgers, sblam, socksproxy, sslbl,
sslproxies, talosintelligence, torproject, trickbot, turris, urlhaus,
viriback, vxvault, zeustrackermonitor, zeustrackerurl, etc.
A partir de las entradas estáticas, los rastros de las siguientes entidades maliciosas (por ejemplo, C&C de malware o sumideros) se han incluido manualmente (a partir de varios informes antivirus e investigaciones personales):
1ms0rry, 404, 9002, aboc, absent, ab, acbackdoor, acridrain, activeagent,
adrozek, advisorbot, adwind, adylkuzz, adzok, afrodita, agaadex, agenttesla,
aldibot, alina, allakore, almalocker, almashreq, alpha, alureon, amadey,
amavaldo, amend_miner, ammyyrat, android_acecard, android_actionspy,
android_adrd, android_ahmythrat, android_alienspy, android_andichap,
android_androrat, android_anubis, android_arspam, android_asacub,
android_backflash, android_bankbot, android_bankun, android_basbanke,
android_basebridge, android_besyria, android_blackrock, android_boxer,
android_buhsam, android_busygasper, android_calibar, android_callerspy,
android_camscanner, android_cerberus, android_chuli, android_circle,
android_claco, android_clickfraud, android_cometbot, android_cookiethief,
android_coolreaper, android_copycat, android_counterclank, android_cyberwurx,
android_darkshades, android_dendoroid, android_dougalek, android_droidjack,
android_droidkungfu, android_enesoluty, android_eventbot, android_ewalls,
android_ewind, android_exodus, android_exprespam, android_fakeapp,
android_fakebanco, android_fakedown, android_fakeinst, android_fakelog,
android_fakemart, android_fakemrat, android_fakeneflic, android_fakesecsuit,
android_fanta, android_feabme, android_flexispy, android_fobus,
android_fraudbot, android_friend, android_frogonal, android_funkybot,
android_gabas, android_geinimi, android_generic, android_geost,
android_ghostpush, android_ginmaster, android_ginp, android_gmaster,
android_gnews, android_godwon, android_golddream, android_goldencup,
android_golfspy, android_gonesixty, android_goontact, android_gplayed,
android_gustuff, android_gypte, android_henbox, android_hiddad,
android_hydra, android_ibanking, android_joker, android_jsmshider,
android_kbuster, android_kemoge, android_ligarat, android_lockdroid,
android_lotoor, android_lovetrap, android_malbus, android_mandrake,
android_maxit, android_mobok, android_mobstspy, android_monokle,
android_notcompatible, android_oneclickfraud, android_opfake,
android_ozotshielder, android_parcel, android_phonespy, android_pikspam,
android_pjapps, android_qdplugin, android_raddex, android_ransomware,
android_redalert, android_regon, android_remotecode, android_repane,
android_riltok, android_roamingmantis, android_roidsec, android_rotexy,
android_samsapo, android_sandrorat, android_selfmite, android_shadowvoice,
android_shopper, android_simbad, android_simplocker, android_skullkey,
android_sndapps, android_spynote, android_spytekcell, android_stels,
android_svpeng, android_swanalitics, android_teelog, android_telerat,
android_tetus, android_thiefbot, android_tonclank, android_torec,
android_triada, android_uracto, android_usbcleaver, android_viceleaker,
android_vmvol, android_walkinwat, android_windseeker, android_wirex,
android_wolfrat, android_xavirad, android_xbot007, android_xerxes,
android_xhelper, android_xploitspy, android_z3core, android_zertsecurity,
android_ztorg, andromeda, antefrigus, antibot, anubis, anuna, apocalypse,
apt_12, apt_17, apt_18, apt_23, apt_27, apt_30, apt_33, apt_37, apt_38,
apt_aridviper, apt_babar, apt_bahamut, etc.
Maltrail se basa en la arquitectura Tráfico -> Sensor <-> Servidor <-> Cliente . Los sensores son un componente independiente que se ejecuta en el nodo de monitoreo (por ejemplo, una plataforma Linux conectada pasivamente al puerto SPAN/duplicación o de forma transparente en línea en un puente Linux) o en la máquina independiente (por ejemplo, Honeypot) donde "monitorea" el tráfico que pasa. para elementos/senderos en la lista negra (es decir, nombres de dominio, URL y/o IP). En caso de una coincidencia positiva, envía los detalles del evento al servidor (central) donde se almacenan dentro del directorio de registro apropiado (es decir, LOG_DIR descrito en la sección Configuración ). Si Sensor se ejecuta en la misma máquina que el servidor (configuración predeterminada), los registros se almacenan directamente en el directorio de registro local. De lo contrario, se envían mediante mensajes UDP al servidor remoto (es decir, LOG_SERVER descrito en la sección Configuración ).
La función principal del servidor es almacenar los detalles del evento y proporcionar soporte de back-end para la aplicación web de informes. En la configuración predeterminada, el servidor y el sensor se ejecutarán en la misma máquina. Por lo tanto, para evitar posibles interrupciones en las actividades de los sensores, la parte de informes frontales se basa en la arquitectura de "cliente pesado" (es decir, todo el posprocesamiento de datos se realiza dentro de la instancia del navegador web del cliente). Los eventos (es decir, entradas de registro) durante el período elegido (24 horas) se transfieren al Cliente , donde la aplicación web de informes es la única responsable de la parte de presentación. Los datos se envían al cliente en fragmentos comprimidos, donde se procesan secuencialmente. El informe final se crea en una forma muy condensada, lo que prácticamente permite la presentación de un número prácticamente ilimitado de eventos.
Nota: El componente del servidor se puede omitir por completo y simplemente usar el Sensor independiente. En tal caso, todos los eventos se almacenarían en el directorio de registro local, mientras que las entradas del registro podrían examinarse manualmente o mediante alguna aplicación de lectura CSV.
Aquí se pueden encontrar páginas de demostración completamente funcionales con amenazas recopiladas de la vida real.
Para ejecutar Maltrail correctamente, se requiere Python 2.6 , 2.7 o 3.x en el sistema *nix/BSD, junto con el paquete pcapy-ng instalado.
NOTA: El uso de pcapy lib en lugar de pcapy-ng puede provocar un funcionamiento incorrecto de Maltrail, especialmente en entornos Python 3.x. Ejemplos.
El componente del sensor requiere al menos 1 GB de RAM para ejecutarse en modo de proceso único o más si se ejecuta en modo de multiprocesamiento, según el valor utilizado para la opción CAPTURE_BUFFER . Además, el componente Sensor (en el caso general) requiere privilegios administrativos/root.
El componente del servidor no tiene ningún requisito especial.
El siguiente conjunto de comandos debería hacer que su sensor Maltrail esté en funcionamiento (listo para usar con la configuración predeterminada y la interfaz de monitoreo "cualquiera"):
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pysudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pyPara iniciar el servidor (opcional) en la misma máquina, abra una nueva terminal y ejecute lo siguiente:
[[ -d maltrail ]] || git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
python server.pyPara probar que todo está funcionando ejecuta lo siguiente:
ping -c 1 136.161.101.53
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logAdemás, para probar la captura de tráfico DNS puedes probar lo siguiente:
nslookup morphed.ru
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logPara detener las instancias de Sensor y Servidor (si se ejecutan en segundo plano), ejecute lo siguiente:
sudo pkill -f sensor.py
pkill -f server.py Acceda a la interfaz de informes (es decir, Cliente ) visitando http://127.0.0.1:8338 (credenciales predeterminadas: admin:changeme! ) desde su navegador web:
La configuración del sensor se puede encontrar dentro de la sección [Sensor] del archivo maltrail.conf :
Si la opción USE_MULTIPROCESSING se establece en true , se utilizarán todos los núcleos de la CPU. Un núcleo se usará solo para la captura de paquetes (con afinidad adecuada, prioridad de IO y configuraciones de nivel agradables), mientras que otros núcleos se usarán para el procesamiento de paquetes. De lo contrario, todo se ejecutará en un único núcleo. La opción USE_FEED_UPDATES se puede usar para desactivar por completo las actualizaciones de rutas de los feeds (y solo usar las estáticas proporcionadas). La opción UPDATE_PERIOD contiene la cantidad de segundos entre cada actualización automática de senderos (Nota: el valor predeterminado se establece en 86400 (es decir, un día)) mediante el uso de definiciones dentro del directorio trails (Nota: tanto el sensor como el servidor se encargan de la actualización de los senderos). El usuario puede utilizar la opción CUSTOM_TRAILS_DIR para proporcionar la ubicación del directorio que contiene los archivos de rutas personalizadas ( *.txt ).
La opción USE_HEURISTICS activa mecanismos heurísticos (por ejemplo, long domain name (suspicious) , excessive no such domain name (suspicious) , direct .exe download (suspicious) , etc.), lo que puede introducir falsos positivos. La opción CAPTURE_BUFFER presenta una memoria total (en bytes de porcentaje de la memoria física total) que se utilizará en el caso del modo de multiprocesamiento para almacenar la captura de paquetes en un búfer de anillo para su posterior procesamiento mediante procesos que no son de captura. La opción MONITOR_INTERFACE debe contener el nombre de la interfaz de captura. Utilice el valor any para capturar desde todas las interfaces (si el sistema operativo lo admite). La opción CAPTURE_FILTER debe contener el filtro de captura de red ( tcpdump ) para omitir los paquetes que no son interesantes y facilitar el proceso de captura. La opción SENSOR_NAME contiene el nombre que debería aparecer dentro del valor de eventos sensor_name , para que el evento de un sensor pueda distinguirse del otro. Si se configura la opción LOG_SERVER , entonces todos los eventos se envían de forma remota al servidor ; de lo contrario, se almacenan directamente en el directorio de registro configurado con la opción LOG_DIR , que se puede encontrar dentro de la sección [All] del archivo maltrail.conf . En caso de que esté configurada la opción UPDATE_SERVER , todos los senderos se extraerán de la ubicación dada; de lo contrario, se actualizarán desde las definiciones de senderos ubicadas dentro de la instalación misma.
Las opciones SYSLOG_SERVER y/o LOGSTASH_SERVER se pueden utilizar para enviar eventos de sensores (es decir, datos de registro) a servidores que no sean Maltrail. En el caso de SYSLOG_SERVER , los datos del evento se enviarán en formato CEF ( formato de evento común ) al servicio UDP (por ejemplo, Syslog) que escucha en la dirección proporcionada (por ejemplo, 192.168.2.107:514 ), mientras que en el caso de LOGSTASH_SERVER los datos del evento se enviarán en Formato JSON para el servicio UDP (por ejemplo, Logstash) que escucha en la dirección dada (por ejemplo, 192.168.2.107:5000 ).
Un ejemplo de datos de eventos que se envían a través de UDP es el siguiente:
SYSLOG_SERVER (Nota: los valores LogSeverity son 0 (bajo), 1 (medio) y 2 (alto)): Dec 24 15:05:55 beast CEF:0|Maltrail|sensor|0.27.68|2020-12-24|andromeda (malware)|2|src=192.168.5.137 spt=60453 dst=8.8.8.8 dpt=53 trail=morphed.ru ref=(static)
LOGSTASH_SERVER : {"timestamp": 1608818692, "sensor": "beast", "severity": "high", "src_ip": "192.168.5.137", "src_port": 48949, "dst_ip": "8.8.8.8", "dst_port": 53, "proto": "UDP", "type": "DNS", "trail": "morphed.ru", "info": "andromeda (malware)", "reference": "(static)"}
Cuando se ejecuta el sensor (por ejemplo, sudo python sensor.py ) por primera vez y/o después de un período más prolongado sin ejecutarse, actualizará automáticamente los senderos a partir de las definiciones de senderos (Nota: almacenados dentro del directorio trails ). Después de la inicialización, comenzará a monitorear la interfaz configurada (opción MONITOR_INTERFACE dentro de maltrail.conf ) y escribirá los eventos en el directorio de registro configurado (opción LOG_DIR dentro de la sección [All] del archivo maltrail.conf ) o los enviará de forma remota al Servidor de registro/informes (opción LOG_SERVER ).
Los eventos detectados se almacenan dentro del directorio de registro del servidor (es decir, la opción LOG_DIR dentro de la sección [All] del archivo maltrail.conf ) en formato CSV fácil de leer (Nota: el espacio en blanco '' se utiliza como delimitador) como entradas de una sola línea. que consta de: sensor time src_ip src_port dst_ip dst_port proto trail_type trail trail_info reference (por ejemplo, "2015-10-19 15:48:41.152513" beast 192.168.5.33 32985 8.8.8.8 53 UDP DNS 0000mps.webpreview.dsl.net malicious siteinspector.comodo.com ):
La configuración del servidor se puede encontrar dentro de la sección maltrail.conf [Server] :
La opción HTTP_ADDRESS contiene la dirección de escucha del servidor web (Nota: utilice 0.0.0.0 para escuchar en todas las interfaces). La opción HTTP_PORT contiene el puerto de escucha del servidor web. El puerto de escucha predeterminado está configurado en 8338 . Si la opción USE_SSL está configurada como true , se utilizará SSL/TLS para acceder al servidor web (por ejemplo, https://192.168.6.10:8338/ ). En ese caso, la opción SSL_PEM debería apuntar al archivo PEM privado/certificado del servidor.
La subsección USERS contiene los ajustes de configuración del usuario. Cada entrada de usuario consta del username:sha256(password):UID:filter_netmask(s) . El valor UID representa el identificador de usuario único, donde se recomienda utilizar valores inferiores a 1000 para cuentas administrativas, mientras que un valor superior para cuentas no administrativas. La parte filter_netmask(s) representa los filtros rígidos delimitados por comas que se pueden usar para filtrar los eventos mostrados según las cuentas de usuario. La entrada predeterminada es la siguiente:
La opción UDP_ADDRESS contiene la dirección de escucha de recopilación de registros del servidor (Nota: use 0.0.0.0 para escuchar en todas las interfaces), mientras que la opción UDP_PORT contiene el valor del puerto de escucha. Si está activado, cuando se usa en combinación con la opción LOG_SERVER , se puede usar para una arquitectura de servidor <-> de sensor distinta (múltiple).
La opción FAIL2BAN_REGEX contiene la expresión regular (por ejemplo, attacker|reputation|potential[^"]*(web scan|directory traversal|injection|remote code|iot-malware download|spammer|mass scanner ) que se usará en las llamadas web /fail2ban para extracción de las IP de origen de los atacantes actuales. Esto permite el uso de mecanismos de bloqueo de IP (por ejemplo, fail2ban , iptables o ipset ) mediante la extracción periódica de las mismas. Direcciones IP incluidas en la lista negra desde una ubicación remota. Un ejemplo de uso sería el siguiente script (por ejemplo, ejecutarlo como un cronjob root cada minuto):
#! /bin/bash
ipset -q flush maltrail
ipset -q create maltrail hash:net
for ip in $( curl http://127.0.0.1:8338/fail2ban 2> /dev/null | grep -P ' ^[0-9.]+$ ' ) ; do ipset add maltrail $ip ; done
iptables -I INPUT -m set --match-set maltrail src -j DROP La opción BLACKLIST permite crear expresiones regulares para aplicar en un campo. Para cada regla, la sintaxis es: <field> <control> <regexp> donde:
field indica el campo a comparar, puede ser: src_ip , src_port , dst_ip , dst_port , protocol , type , trail o filter .control puede ser ~ para coincidencias o !~ para no coincidencias.regexp es la expresión regular que se aplicará al campo. Encadene otra regla con la palabra clave and (la palabra clave or no es compatible, solo agregue una línea para esto). Puede utilizar la palabra clave BLACKLIST sola o agregar un nombre: BLACKLIST_NAME . En el último caso, la URL será: /blacklist/name
Por ejemplo, lo siguiente creará una lista negra para todo el tráfico de otra fuente que no sea 192.168.0.0/16 al puerto de destino SSH o que coincida con el scan de filtros o known attacker
BLACKLIST_OUT
src_ip !~ ^192.168. and dst_port ~ ^22$
src_ip !~ ^192.168. and filter ~ scan
src_ip !~ ^192.168. and filter ~ known attacker
BLACKLIST_IN
src_ip ~ ^192.168. and filter ~ malware
La forma de crear una lista negra de ipset es la misma (ver arriba), excepto que las URL serán /blacklist/in y /blacklist/out en nuestro ejemplo.
Lo mismo que para Sensor , cuando se ejecuta el servidor (por ejemplo, python server.py ) por primera vez y/o después de un período más prolongado sin ejecución, si la opción USE_SERVER_UPDATE_TRAILS está configurada en true , actualizará automáticamente los senderos a partir de las definiciones de senderos ( Nota: almacenado dentro del directorio trails ). Su función básica es almacenar las entradas de registro dentro del directorio de registro (es decir, la opción LOG_DIR dentro de la sección [All] del archivo maltrail.conf ) y proporcionar la interfaz web de informes para presentar esas mismas entradas al usuario final (Nota: no hay necesita instalar paquetes de servidores web de terceros como Apache):
Al ingresar a la interfaz de informes del servidor (es decir, a través de la dirección definida por las opciones HTTP_ADDRESS y HTTP_PORT ), se presentará al usuario el siguiente cuadro de diálogo de autenticación. El usuario debe ingresar las credenciales adecuadas que fueron configuradas por el administrador del servidor dentro del archivo de configuración maltrail.conf (Nota: las credenciales predeterminadas son admin:changeme! ):
Una vez dentro, al usuario se le presentará la siguiente interfaz de informes:
La parte superior contiene una línea de tiempo deslizante (Nota: se activa después de hacer clic en la etiqueta de la fecha actual y/o en el ícono del calendario) donde el usuario puede seleccionar registros de eventos pasados (Nota: al pasar el mouse sobre el evento se mostrará información sobre herramientas con un número aproximado de eventos para el evento actual). fecha). Las fechas se agrupan por meses, donde se muestran datos de un período de 4 meses dentro del propio widget. Sin embargo, al utilizar el control deslizante proporcionado (es decir), el usuario puede acceder fácilmente a eventos de meses anteriores.
Una vez que se hace clic en la fecha, todos los eventos para esa fecha en particular deben cargarse y representarse en el navegador web del cliente. Dependiendo del número de eventos y de la velocidad de la conexión de red, la carga y visualización de los eventos registrados puede tardar desde un par de segundos hasta varios minutos (por ejemplo, 100.000 eventos tardan unos 5 segundos en total). Durante todo el tiempo de procesamiento, el cargador animado se mostrará en la interfaz de usuario deshabilitada:
La parte central contiene un resumen de los eventos mostrados. El cuadro Events representa el número total de eventos en un período seleccionado de 24 horas, donde la línea roja representa eventos basados en IP, la línea azul representa eventos basados en DNS y la línea amarilla representa eventos basados en URL. El cuadro Sources representa el número de eventos por fuentes principales en forma de un gráfico de columnas apiladas, con el número total de fuentes en la parte superior. El cuadro Threats representa el porcentaje de las principales amenazas en forma de gráfico circular (Nota: el área gris contiene todas las amenazas que tienen <1 % cada una en el total de eventos), con el número total de amenazas en la parte superior. El cuadro Trails representa el porcentaje de los senderos principales en forma de gráfico circular (Nota: el área gris contiene todos los senderos que tienen <1% cada uno en el total de eventos), con el número total de senderos en la parte superior. Cada uno de esos cuadros está activo, por lo tanto, al hacer clic en uno de ellos se obtendrá un gráfico más detallado.
La parte inferior contiene una representación condensada de los eventos registrados en forma de tabla paginada. Cada entrada contiene detalles para una única amenaza (Nota: identificada de forma única por un par (src_ip, trail) o (dst_ip, trail) si src_ip es el mismo que el trail como en el caso de ataques provenientes del exterior):
La columna threat contiene el ID único de la amenaza (p. ej., 85fdb08d ) y el color (Nota: extruido del ID de la amenaza), sensor contiene los nombres de los sensores donde se activó el evento (p. ej., blitvenica ), events contienen el número total de eventos para una amenaza actual. , severity contiene la gravedad evaluada de la amenaza (Nota: calculada en función de los valores de las columnas info y reference , priorizando el tráfico generado por malware), first_seen contiene la hora del primer evento en un período seleccionado (24 horas) (p. ej. 06th 08:21:54 ), last_seen contiene la hora del último evento en un período seleccionado (24 h) (por ejemplo, 06th 15:21:23 ), sparkline contiene un pequeño gráfico minigráfico que representa la actividad de la amenaza en el período seleccionado, src_ip contiene IP de origen ) de una amenaza (por ejemplo, 99.102.41.102 ), src_port contiene los puertos de origen (por ejemplo, 44556, 44589, 44601 ), dst_ip contiene IP(s) de destino (por ejemplo, 213.202.100.28 ), dst_port contiene puerto(s) de destino (por ejemplo, 80 (HTTP) ), proto contiene protocolo(s), (por ejemplo, TCP ), retención trail una entrada en la lista negra (o heurística) que desencadenó los eventos, info contiene más información sobre la amenaza/rastro (por ejemplo, known attacker para las direcciones IP del atacante conocido o ipinfo para el servicio de información de IP conocido comúnmente utilizado por el malware durante un inicio), reference contiene una fuente de la entrada en la lista negra (por ejemplo, (static) para pistas estáticas o myip.ms para una fuente dinámica recuperada de esa misma fuente) y tags contienen etiquetas definidas por el usuario para una ruta determinada (por ejemplo, APT28 ).
Al mover el mouse sobre las entradas de las tablas src_ip y dst_ip , se muestra información sobre herramientas con información detallada de DNS inverso y WHOIS (Nota: RIPE es el proveedor de información):
Los detalles del evento (por ejemplo, src_port , dst_port , proto , etc.) que difieren dentro de la misma entrada de amenaza se condensan en forma de un icono de burbuja (es decir). Esto se realiza para obtener una interfaz de informes utilizable con la menor cantidad de filas posible. Al mover el mouse sobre dicho ícono, se mostrará una información sobre herramientas con todos los elementos retenidos (por ejemplo, todos los números de puerto escaneados por attacker ):
Al hacer clic en uno de esos íconos, se abrirá un nuevo cuadro de diálogo que contiene todos los elementos almacenados (Nota: en su forma no condensada) listos para copiar y pegar (d) para su posterior análisis:
Al pasar el puntero del mouse sobre el rastro de la amenaza durante un par de segundos, aparecerá un cuadro que consta de resultados que utilizan el rastro como término de búsqueda realizado contra Buscar cifrar motor de búsqueda busqueX. En muchos casos, esto proporciona información básica sobre la amenaza en sí, eliminando la necesidad de que el usuario realice una búsqueda manual. En la esquina superior derecha de la ventana del marco abierto hay dos botones adicionales. Al hacer clic en el primero (es decir), el marco resultante se abrirá dentro de la nueva pestaña (o ventana) del navegador, mientras que al hacer clic en el segundo (es decir), se cerrará inmediatamente el marco (Nota: la misma acción se logra moviendo el puntero del mouse fuera de los bordes del marco):
Para cada amenaza hay una tag de columna que se puede llenar con "etiquetas" arbitrarias para describir detalladamente todas las amenazas que comparten el mismo rastro. Además, es una excelente manera de describir las amenazas individualmente, de modo que todas las amenazas que comparten la misma etiqueta (por ejemplo, yahoo ) se puedan agrupar más adelante:
En la siguiente sección se describirán algunos de los escenarios de "sospechosos habituales" a través de casos de la vida real.
Los escaneos masivos son un fenómeno bastante común donde individuos y/u organizaciones se dan el derecho de escanear todo el rango de IP 0.0.0.0/0 (es decir, todo Internet) diariamente, con un descargo de responsabilidad donde dicen que si no le gusta entonces debe comunicarse con ellos de forma privada para que lo omitan en análisis futuros.
Para empeorar las cosas, organizaciones como Shodan y ZoomEye dan todos los resultados a disposición gratuita (para otros atacantes potenciales) a través de su motor de búsqueda. En las siguientes capturas de pantalla verás detalles de los escaneos de Shodan en un solo día.
Aquí hay una búsqueda inversa de DNS y WHOIS de la dirección del "atacante":
Al pasar el puntero del mouse sobre el contenido de la columna de trail (dirección IP), se le presentarán los resultados de búsqueda de searX, donde podrá encontrar más información sobre el "atacante":
En la columna dst_ip , si tiene una organización grande, se le presentará una lista grande de direcciones IP escaneadas:
En la columna dst_port podrá ver todos los puertos que han sido analizados mediante dichos análisis masivos:
En otras situaciones similares, verá el mismo comportamiento, proveniente de atacantes individuales incluidos en la lista negra (en este caso, por cinsscore.com):
Un comportamiento más común es escanear todo el rango de IP 0.0.0.0/0 (es decir, Internet) en busca de un puerto en particular (por ejemplo, el puerto TCP 443 cuando se ha encontrado Heartbleed). En la siguiente captura de pantalla encontrará uno de esos casos de atacantes previamente incluidos en la lista negra (en este caso, alienvault.com y otras dos listas negras) que apuntan al puerto UDP 5060 (es decir, SIP) en busca de dispositivos VoIP mal configurados:
Para detectar a los atacantes potenciales escondidos detrás de la red de anonimato de Tor, Maltrail utiliza listas de nodos de salida de Tor disponibles públicamente. En la siguiente captura de pantalla verá un caso en el que un atacante potencial ha estado utilizando la red Tor para acceder al objetivo web (a través de HTTP) en el rango de nuestra organización de manera sospechosa (un total de 171 solicitudes de conexión en 10 minutos):
Un caso bastante similar al anterior es cuando un atacante previamente incluido en la lista negra intenta acceder a un servicio particular (por ejemplo, no HTTP(s)) en el rango de nuestra organización de manera bastante sospechosa (es decir, un total de 1513 intentos de conexión en menos de 15 minutos):
Si ingresamos el ssh attacker en el campo Filter , podremos ver todos los sucesos similares para ese día, pero en este caso para el puerto 22 (es decir, SSH):
En caso de intentos de conexión provenientes de equipos infectados dentro de nuestra organización hacia servidores C&C ya conocidos, podrá encontrar amenazas similares a las siguientes (en este caso Beebone):
En el caso de solicitudes de DNS que contengan nombres de dominio DGA conocidos, la amenaza se mostrará como (en este caso Necurs):
En el siguiente caso, se han producido descargas de archivos desde URL incluidas en la lista negra (en este caso, de malwarepatrol.net):
Si ingresamos el nombre del malware en particular (en este caso Ramnit) en el campo Filter , solo se filtrarán las amenazas que se sabe que están vinculadas a este malware (mostrando todas las computadoras internas afectadas):
De manera más general, si ingresamos el malware en el campo Filter , todas las amenazas que hayan sido encontradas por rastros (relacionados) con malware (por ejemplo, direcciones IP ) se filtrarán en:
Maltrail utiliza la lista estática de dominios TLD que se sabe que suelen estar involucrados en actividades sospechosas. La mayoría de estos dominios TLD provienen de registradores de dominios gratuitos (por ejemplo, Freenom), por lo que deberían estar bajo un mayor escrutinio. En la siguiente captura de pantalla podemos encontrar un caso en el que un malware desconocido utilizó uno de esos dominios TLD .cm utilizando el algoritmo DGA para contactar con su(s) servidor(es) C&C:
También hay casos en los que dominios TLD perfectamente válidos (por ejemplo, .ru ) se utilizan para actividades sospechosas, como en este caso (por ejemplo, long domain name (suspicious) ) donde los dominios son obviamente DGA generados por malware desconocido:
Maltrail utiliza una lista estática de los llamados "dominios dinámicos" que a menudo se utilizan en actividades sospechosas (por ejemplo, para servidores C&C de malware que a menudo cambian las direcciones IP del destino):
Además, Maltrail utiliza una lista estática de dominios relacionados con "cebolla" que también se utilizan a menudo en actividades sospechosas (por ejemplo, malware que contacta servidores C&C mediante el uso de servicios Tor2Web):
En el caso de malware antiguo y/u obsoleto que permanece sin ser detectado en las computadoras internas infectadas de la organización, a menudo hay un "fenómeno" en el que el malware intenta continuamente contactar con el dominio del servidor C&C inactivo hace mucho tiempo sin ninguna resolución DNS. Por lo tanto, ese tipo de amenazas (potenciales) se marcarán como excessive no such domain (suspicious) :
En caso de que un rastro sea responsable de demasiadas amenazas (por ejemplo, en el caso de IP de origen falsas como en los ataques de amplificación de DNS), todas las amenazas similares se agruparán bajo una única amenaza flood (Nota: el ID de la amenaza se marcará con el sufijo F0 ). como en el siguiente ejemplo:
Muchos programas maliciosos utilizan algún tipo de servicio ipinfo (por ejemplo, ipinfo.io) para averiguar la dirección IP de Internet de la víctima. En caso de solicitudes regulares y especialmente fuera del horario de oficina, ese tipo de solicitudes deben monitorearse de cerca, como en el siguiente ejemplo:
Al utilizar el filtro ipinfo se pueden enumerar todos los ordenadores potencialmente infectados dentro del alcance de nuestra organización que comparten este tipo de comportamiento sospechoso:
Maltrail rastrea todos los intentos de descarga directa de archivos sospechosos (por ejemplo, .apk , .bin , .class , .chm , .dll , .egg , .exe , .hta , .hwp , .lnk , .ps1 , .scr , .sct , .wbk extensiones de archivo .wbk y .xpi ). Esto puede generar muchos falsos positivos, pero eventualmente podría ayudar a reconstruir la cadena de infección (Nota: los proveedores de servicios legítimos, como Google, generalmente usan HTTPS cifrado para realizar este tipo de descargas):
En caso de solicitudes sospechosas provenientes de escáneres de seguridad de aplicaciones web externas (por ejemplo, búsqueda de vulnerabilidades SQLi, XSS, LFI, etc.) y/o intentos maliciosos del usuario interno hacia sitios web desconocidos, se podrían encontrar amenazas como las siguientes (caso real de atacantes que intentan aprovechar las vulnerabilidades CVE-2015-7297, CVE-2015-7857 y CVE-2015-7858 de Joomla!
En el siguiente ejemplo, el análisis de vulnerabilidades de aplicaciones web se ha marcado como "sospechoso":
Si hacemos clic en el ícono de burbuja (es decir, ) para obtener detalles y copiamos y pegamos todo el contenido en un archivo de texto, podremos ver todas las solicitudes HTTP sospechosas:
En la siguiente captura de pantalla, se puede encontrar una ejecución de la popular herramienta de vulnerabilidad SQLi sqlmap dentro de nuestros registros:
En caso de demasiados intentos de conexión hacia una cantidad considerable de puertos TCP diferentes, Maltrail advertirá sobre el posible escaneo de puertos, como resultado de su detección de mecanismo heurístico. En la siguiente captura de pantalla se pueden encontrar dichas advertencias para una ejecución de la popular herramienta de escaneo de puertos nmap:
Un ataque DDoS popular contra la infraestructura de los servidores web es el agotamiento de los recursos de su servidor DNS (principal) al realizar consultas recursivas de DNS válidas para nombres de subdominios (pseudo)aleatorios (por ejemplo, abpdrsguvjkyz.www.dedeni.com ):
Varios programas (especialmente los basados en dispositivos móviles) presentan un comportamiento similar al de malware en el que envían datos potencialmente confidenciales a las publicaciones de baliza remotas. Maltrail intentará capturar dicho comportamiento como en el siguiente ejemplo:
Como ocurre con todas las demás soluciones de seguridad, Maltrail es propenso a generar "falsos positivos". En ese tipo de casos, Maltrail (especialmente en el caso de amenazas suspicious ) registrará el comportamiento de un usuario normal y lo marcará como malicioso y/o sospechoso. En el siguiente ejemplo se puede ver que un proveedor de feeds de lista negra, blocklist.de marcó el servidor normal de Google como attacker (s), lo que generó la siguiente amenaza:
Al pasar el mouse sobre el rastro, el cuadro con los resultados de la búsqueda de SearX muestra que este es (muy probablemente) un servidor normal de Google:
Como otro ejemplo, el acceso a dominios .work normales (TLD popular con fines maliciosos) resultó en la siguiente amenaza:
Sin embargo, los administradores deberían invertir algo de tiempo extra y comprobar (con otros medios) si "sospechoso" significa malicioso o no, como en el siguiente ejemplo:
En Ubuntu/Debian
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailEn SUSE/openSUSE
sudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailEstablecer ambiente de trabajo:
sudo mkdir -p /var/log/maltrail
sudo mkdir -p /etc/maltrail
sudo cp /opt/maltrail/maltrail.conf /etc/maltrail
sudo nano /etc/maltrail/maltrail.confEstablecer el entorno de ejecución:
crontab -e # autostart server & periodic update */5 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'server.py')" ]; then : ; else python3 /opt/maltrail/server.py -c /etc/maltrail/maltrail.conf; fi
0 1 * * * cd /opt/maltrail && git pull
sudo crontab -e # autostart sensor & periodic restart */1 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'sensor.py')" ]; then : ; else python3 /opt/maltrail/sensor.py -c /etc/maltrail/maltrail.conf; fi
2 1 * * * /usr/bin/pkill -f maltrail
Habilitar como servicios systemd (solo Linux):
sudo cp /opt/maltrail/maltrail-sensor.service /etc/systemd/system/maltrail-sensor.service
sudo cp /opt/maltrail/maltrail-server.service /etc/systemd/system/maltrail-server.service
sudo systemctl daemon-reload
sudo systemctl start maltrail-server.service
sudo systemctl start maltrail-sensor.service
sudo systemctl enable maltrail-server.service
sudo systemctl enable maltrail-sensor.service
systemctl status maltrail-server.service && systemctl status maltrail-sensor.service
Nota : /maltrail-sensor.service se puede iniciar como servicio dedicado sin /maltrail-server.service preiniciado. Esto es útil en el caso de que /maltrail-server.service esté instalado y funcione en otra máquina de su entorno de red.
Este software se proporciona bajo una licencia MIT. Consulte el archivo de LICENCIA adjunto para obtener más información.
1 Usando (solo) senderos
2 Conector a senderos (solo)
