Durante la semana 36 de 2026, nuestro SOC analizó 1.975 indicadores de compromiso SonicWall generados por firewalls SonicWall TZ270 y TZ370 desplegados en diferentes entornos empresariales.
Los eventos revisados estuvieron relacionados principalmente con:
- Port Scan Possible
- SMTP Server on RBL Blacklist
Es importante interpretar correctamente estas cifras.
1.975 indicadores no significan 1.975 ataques confirmados ni 1.975 sistemas comprometidos.
SonicWall registra actividad y genera eventos de seguridad.
Después, nuestro SOC analiza los logs, revisa su contexto y determina qué actividad puede corresponder a tráfico legítimo, exploración automatizada, infraestructura de hosting, reputación negativa o una situación que realmente necesita investigación.
¿Qué son los indicadores de compromiso SonicWall?
Los indicadores de compromiso SonicWall son señales que pueden ayudar a identificar actividad que merece revisión.
Pueden estar relacionados con:
- direcciones y redes con mala reputación;
- escaneos;
- servicios publicados;
- intentos de conexión;
- servidores incluidos en listas de reputación;
- patrones anómalos.
Sin embargo:
un indicador no equivale automáticamente a un compromiso.
Por eso necesitamos analizar:
origen + destino + servicio + frecuencia + contexto + comportamiento posterior.
1.975 eventos analizados, pero no 1.975 incidentes
Esta diferencia es fundamental.
Un mismo origen puede:
- realizar múltiples intentos;
- comprobar varios puertos;
- aparecer repetidamente durante una semana.
Además, Internet recibe constantemente tráfico automatizado procedente de:
- escáneres;
- bots;
- sistemas de monitorización;
- servicios cloud;
- redes de hosting.
Por tanto, contabilizar eventos sin contexto podría ofrecer una imagen distorsionada del riesgo.
Nuestro trabajo consiste en reducir ese ruido.
Port Scan Possible: el evento más habitual en Internet
Uno de los eventos revisados durante la semana fue:
Port Scan Possible
Un escaneo de puertos intenta comprobar qué servicios responden en una dirección pública.
Por ejemplo:
- HTTPS;
- SSH;
- VPN;
- correo;
- RDP;
- servicios administrativos.
Un escaneo puede preceder a un ataque.
Pero también puede ser simplemente:
reconocimiento automatizado de Internet.
Por eso no debemos afirmar que cada Port Scan Possible representa una intrusión.
¿Por qué se escanean continuamente las IP públicas?
Porque existen sistemas automatizados que recorren Internet buscando:
- servidores expuestos;
- VPN;
- firewalls;
- cámaras;
- routers;
- NAS;
- servicios vulnerables.
El proceso puede ser completamente automático.
Un bot puede probar miles de direcciones sin saber qué empresa hay detrás.
Por eso incluso una pequeña pyme puede recibir actividad de reconocimiento.
No es necesario ser una gran multinacional para aparecer en estos escaneos.
Indicadores de compromiso SonicWall y superficie de ataque
Un escaneo adquiere mayor importancia cuando encuentra un servicio realmente expuesto.
Por ejemplo:
Internet → RDP
o:
Internet → administración del firewall
o:
Internet → aplicación antigua
Por eso una de las tareas más importantes en seguridad perimetral es reducir la superficie de ataque.
La pregunta debería ser:
¿Qué servicios tenemos publicados y cuáles siguen siendo realmente necesarios?
SMTP Server on RBL Blacklist: qué significa
El segundo tipo de evento observado fue:
SMTP Server on RBL Blacklist
RBL significa:
Real-time Blackhole List
o lista de reputación utilizada habitualmente en entornos de correo electrónico.
Que un servidor aparezca en una RBL puede estar relacionado con:
- spam;
- abuso previo;
- infraestructura compartida;
- mala reputación;
- actividad histórica.
Sin embargo:
estar en una RBL no significa automáticamente que ese servidor esté distribuyendo malware ni que el firewall haya sufrido un ataque.
Es una señal reputacional que debe analizarse dentro de su contexto.
Una lista RBL ayuda a identificar reputación, no culpabilidad
Imagine una infraestructura de hosting compartida.
Una misma plataforma puede alojar:
- empresas legítimas;
- aplicaciones;
- servidores;
- servicios maliciosos.
Por eso debemos evitar concluir:
“el proveedor es malicioso”.
Lo correcto es decir:
“se ha observado tráfico asociado a infraestructura alojada en esa red o proveedor.”
¿De dónde procedían los eventos de la semana 36?
El análisis de las redes proporcionadas muestra una presencia importante de infraestructura cloud, VPS y hosting internacional.
Entre los proveedores asociados a parte de las direcciones revisadas aparecen plataformas como:
- Google Cloud
- Microsoft Azure
- DigitalOcean
- OVHcloud
- otras redes de hosting y centros de datos internacionales
Por ejemplo, una de las redes observadas pertenece a OVH, mientras que otra dirección revisada se encuentra en infraestructura de DigitalOcean en Ámsterdam.
También aparece una red registrada en Países Bajos y anunciada mediante infraestructura de comunicaciones europea.
Este patrón es habitual.
Los proveedores cloud permiten desplegar servidores en minutos.
Eso es útil para empresas legítimas.
Pero también significa que esas mismas plataformas pueden ser utilizadas temporalmente para:
- escaneo;
- automatización;
- proxies;
- bots;
- infraestructura de pruebas.
Importante: el proveedor de hosting no es el atacante
Que una conexión proceda de:
OVHcloud
DigitalOcean
Google Cloud
o:
Microsoft Azure
no significa que esas empresas estén detrás de la actividad.
Es fundamental diferenciar:
proveedor de infraestructura
de:
usuario que está utilizando esa infraestructura.
El proveedor ofrece:
- servidores;
- máquinas virtuales;
- almacenamiento;
- red.
Un tercero puede contratar esos recursos.
Por tanto:
hosting observado ≠ identidad del atacante.
Geolocalización de los indicadores de compromiso SonicWall
El listado analizado muestra actividad asociada a infraestructuras distribuidas por varias regiones.
De forma resumida, encontramos presencia en:
- Europa
- Norteamérica
- Asia
Entre los países asociados a redes o centros de datos observados aparecen, entre otros:
- Países Bajos;
- Francia;
- Alemania;
- Estados Unidos;
- diferentes ubicaciones asiáticas.
Sin embargo, la geolocalización de una IP debe interpretarse con prudencia.
Una IP ubicada técnicamente en Países Bajos puede estar siendo utilizada por una persona situada en otro país.
¿Puede saberse desde qué país está realmente el atacante?
No necesariamente.
La geolocalización indica normalmente:
dónde está registrada o alojada la infraestructura.
No siempre:
dónde se encuentra la persona que la utiliza.
Un atacante puede utilizar:
- VPS;
- VPN;
- proxy;
- cloud;
- sistemas comprometidos.
Por tanto, en nuestros análisis evitamos afirmar:
“el atacante está en Francia”
simplemente porque una IP aparece geolocalizada allí.
Lo correcto sería:
“la conexión se observó desde infraestructura geolocalizada o registrada en Francia.”
Europa: presencia relevante de hosting y centros de datos
Parte de las señales revisadas estaban asociadas a redes europeas.
Destaca la presencia de proveedores de infraestructura y hosting.
En el caso de OVH, el rango comprobado pertenece a AS16276 OVH SAS, con infraestructura registrada en Francia y determinados bloques desplegados también en otros países europeos.
También encontramos infraestructura de DigitalOcean en Ámsterdam, Países Bajos.
Este tipo de tráfico es común porque Europa dispone de una gran concentración de centros de datos y servicios VPS.
Norteamérica: grandes plataformas cloud
Una parte importante de las direcciones revisadas pertenece a grandes rangos asociados a plataformas cloud.
Entre ellas aparecen redes utilizadas por:
- Google Cloud;
- Microsoft Azure;
- DigitalOcean.
Estas plataformas disponen de centros de datos distribuidos globalmente.
Por eso la localización del ASN o del proveedor tampoco implica que la actividad proceda físicamente de la sede corporativa del proveedor.
Asia: actividad distribuida
También se observan direcciones asociadas a infraestructura localizada o registrada en diferentes zonas de Asia.
Esto refuerza un patrón habitual:
la exposición de un firewall en Internet es global.
Un equipo instalado en España puede recibir conexiones en pocos minutos desde:
- Europa;
- Estados Unidos;
- Asia.
No existe una frontera geográfica en Internet equivalente a la frontera física.
¿Bloqueó SonicWall estas conexiones?
Aquí es importante no generalizar.
Los eventos facilitados corresponden a:
Port Scan Possible
y:
SMTP Server on RBL Blacklist
Sin el campo concreto de acción de cada registro no sería correcto afirmar que los 1.975 eventos fueron bloqueados.
Dependiendo de:
- regla;
- política;
- servicio;
- acción registrada;
un evento puede haber sido:
- bloqueado;
- permitido;
- detectado;
- registrado.
Por eso nuestro SOC no convierte automáticamente:
evento detectado
en:
ataque bloqueado.
¿Qué ocurre si un escaneo no está bloqueado?
Un escaneo por sí solo no compromete necesariamente el dispositivo.
La pregunta importante es:
¿existía un servicio accesible detrás?
Si la respuesta es no:
el riesgo puede ser reducido.
Si la respuesta es sí:
hay que comprobar:
- qué servicio;
- qué versión;
- por qué está publicado;
- qué autenticación utiliza;
- si existen vulnerabilidades conocidas;
- qué ocurrió después.
Por eso el contexto es fundamental.
Indicadores de compromiso SonicWall y reglas de firewall
Un firewall empresarial debería seguir el principio:
denegar por defecto aquello que no sea necesario.
En lugar de publicar múltiples servicios y tratar de protegerlos posteriormente.
Por ejemplo:
Internet → servidor
solo debería permitirse cuando existe una necesidad real.
Cada regla publicada aumenta la superficie de ataque.
Nunca publicar RDP directamente si puede evitarse
Un ejemplo típico.
En lugar de:
Internet → RDP → servidor
es preferible:
Internet → VPN → autenticación → RDP interno
Esto añade una capa adicional.
Además, permite:
- controlar usuarios;
- registrar sesiones;
- revocar accesos;
- aplicar MFA cuando la solución lo permite.
SonicWall TZ270 y TZ370 en pequeñas y medianas empresas
Los modelos SonicWall TZ270 y TZ370 son especialmente habituales en entornos pyme y despachos profesionales.
En nuestros clientes los administramos en sectores como:
- administraciones de fincas;
- asesorías contables;
- asesorías laborales;
- despachos de abogados;
- arquitectura;
- interiorismo;
- constructoras;
- desarrollos de ingeniería;
- despachos profesionales ubicados en viviendas.
Cada entorno tiene necesidades diferentes.
Por eso las reglas no deberían copiarse de una empresa a otra sin análisis.
Administración de fincas
Una administración de fincas puede trabajar con:
- banca;
- Microsoft 365;
- aplicaciones de gestión;
- certificados;
- documentación de propietarios.
El firewall protege la comunicación entre esta infraestructura e Internet.
Además, puede proporcionar VPN para trabajo remoto.
Asesoría contable y laboral
Una asesoría puede manejar:
- nóminas;
- DNI;
- información fiscal;
- Seguridad Social;
- certificados digitales.
Por ello conviene combinar:
firewall + Endpoint / EDR + MFA + copias + monitorización.
Despachos de abogados
Un despacho jurídico almacena información especialmente sensible.
Además, puede necesitar:
- teletrabajo;
- VPN;
- Microsoft 365;
- NAS;
- servidores.
El firewall es una de las primeras capas.
Pero nunca debería ser la única.
Arquitectura e interiorismo
Estos entornos pueden manejar archivos de gran tamaño y utilizar:
- NAS;
- servidores;
- AutoCAD;
- Revit;
- recursos cloud;
- VPN.
Una interrupción de red puede tener un impacto directo en productividad.
Por tanto, seguridad y disponibilidad deben analizarse conjuntamente.
Constructoras y desarrollos de ingeniería
Estos sectores pueden disponer de:
- oficinas;
- obras;
- sedes;
- conexiones VPN;
- servidores;
- dispositivos remotos.
El perímetro puede volverse más complejo.
Por eso la centralización de eventos aporta visibilidad.
Despachos profesionales en hogar
Trabajar desde una vivienda no elimina el riesgo empresarial.
Un profesional puede manejar:
- información confidencial;
- banca;
- Microsoft 365;
- datos personales;
- certificados.
Un router doméstico no siempre proporciona las mismas capacidades de seguridad y monitorización que un firewall empresarial.
Indicadores de compromiso SonicWall y SIEM Wazuh
Uno de los principales valores de nuestro servicio es que el firewall no trabaja aislado.
Los logs de SonicWall pueden integrarse en SIEM Wazuh.
Después podemos relacionarlos con:
- Windows;
- Microsoft 365;
- antivirus;
- servidores;
- red.
Esto permite intentar responder preguntas como:
¿una IP observada en el firewall aparece también en otro sistema?
¿hubo actividad en un equipo al mismo tiempo?
¿existió un inicio de sesión relacionado?
Una IP por sí sola tiene poco contexto
Imagine que SonicWall registra una dirección externa.
Por sí sola sabemos poco.
Pero si además aparece:
Firewall → conexión externa
Windows → autenticación
Endpoint → proceso anómalo
el conjunto puede adquirir mucha más relevancia.
Ahí entra la correlación.
Correlaciones personalizadas
En GHM Soluciones Informáticas utilizamos correlaciones adaptadas a cada infraestructura.
No todas las empresas necesitan las mismas reglas.
Por ejemplo:
una asesoría puede priorizar:
- Microsoft 365;
- identidad;
- correo;
- firewall.
Una ingeniería puede necesitar:
- servidores;
- NAS;
- VPN;
- red.
El objetivo es reducir falsos positivos y aumentar la utilidad de cada alerta.
Indicadores de compromiso no significa compromiso confirmado
Esta frase merece repetirse.
IoC = señal que merece análisis.
No significa automáticamente:
equipo comprometido.
Un origen puede aparecer en una lista porque:
- participó previamente en escaneos;
- está alojado en una red con mala reputación;
- pertenece a infraestructura compartida;
- existe un reporte histórico.
Después debemos comprobar qué ocurrió realmente en nuestra infraestructura.
¿Qué revisa nuestro SOC?
Ante un evento relevante podemos analizar:
- origen;
- geolocalización;
- ASN;
- proveedor;
- puerto;
- destino;
- repetición;
- horario;
- regla aplicada;
- eventos relacionados.
Después podemos clasificarlo como:
actividad esperada
actividad de reconocimiento
actividad sospechosa
o:
situación que requiere actuación.
¿Por qué conservar logs del firewall?
Porque algunos incidentes se descubren tarde.
Por ejemplo:
hoy aparece una vulnerabilidad.
Entonces queremos comprobar:
¿recibimos tráfico relacionado hace seis meses?
Si el firewall solo conserva unas semanas:
la evidencia puede haberse perdido.
Por eso integramos estos registros dentro de nuestra estrategia de almacenamiento.
Hasta 400 días de histórico de logs
Nuestros servicios de SIEM pueden mantener hasta 400 días de histórico.
Esto facilita:
- investigaciones;
- auditorías;
- búsquedas retrospectivas;
- análisis de tendencias;
- revisión de incidentes.
Así podemos mirar hacia atrás cuando aparece nueva información.
Indicadores de compromiso SonicWall y threat hunting
Cuando aparece:
- una IP;
- un dominio;
- un rango;
- una vulnerabilidad;
podemos buscar retrospectivamente si existe actividad relacionada.
Este proceso permite pasar de:
“tenemos un nuevo indicador”
a:
“¿lo vimos anteriormente en nuestra infraestructura?”
El histórico aporta esa capacidad.
El valor no está en almacenar millones de logs
Guardar logs sin analizarlos tiene un valor limitado.
El objetivo es poder:
buscar
correlacionar
priorizar
investigar
Por eso combinamos:
SonicWall + SIEM Wazuh + SOC.
Firewall administrado frente a firewall instalado
Existe una diferencia importante.
Firewall instalado
Se configura una vez.
Internet funciona.
VPN funciona.
Y solo se revisa cuando aparece un problema.
Firewall administrado
Se revisan:
- firmware;
- reglas;
- VPN;
- usuarios;
- objetos;
- servicios publicados;
- eventos;
- vulnerabilidades.
La seguridad necesita mantenimiento.
¿Cuándo se revisaron por última vez las reglas de tu firewall?
Esta pregunta suele ser más importante que:
“¿Qué marca tienes?”
Una regla creada hace cinco años puede seguir permitiendo un servicio que ya no existe.
Cada excepción innecesaria aumenta la superficie de ataque.
Indicadores de compromiso SonicWall y firmware
El firewall también necesita actualizaciones.
SonicWall publica periódicamente:
- firmware;
- correcciones;
- parches de seguridad.
Por eso un equipo correctamente administrado necesita un ciclo de mantenimiento.
No basta con que siga funcionando.
Seguridad por capas
Un SonicWall puede proteger el perímetro.
Pero no sustituye:
- Endpoint / EDR;
- MFA;
- Microsoft 365;
- copias;
- SIEM;
- SOC.
Una estrategia adecuada combina diferentes controles.
Por ejemplo:
Firewall
controla comunicaciones.
Endpoint / EDR
analiza el dispositivo.
MFA
protege identidad.
SIEM
centraliza registros.
SOC
analiza el contexto.
Semana 36: principales conclusiones
Durante la semana 36 de 2026, nuestro SOC analizó 1.975 indicadores de compromiso SonicWall procedentes de firewalls TZ270 y TZ370.
Los eventos estuvieron relacionados principalmente con:
- posibles escaneos de puertos;
- servidores SMTP incluidos en listas RBL.
La infraestructura observada estaba distribuida internacionalmente y parte de ella estaba asociada a proveedores cloud y hosting como Google Cloud, Microsoft Azure, DigitalOcean y OVHcloud, además de otras redes de centros de datos.
La geolocalización mostró presencia principalmente en:
Europa + Norteamérica + Asia.
Pero estas localizaciones describen la infraestructura observada.
No identifican por sí solas al responsable de la actividad.
Conclusión: 1.975 indicadores de compromiso SonicWall necesitan contexto, no alarmismo
Los indicadores de compromiso SonicWall son una pieza importante dentro de la monitorización del perímetro.
Esta semana analizamos:
1.975 eventos.
Pero nuestra función no consiste en convertir cada evento en:
“ataque”.
SonicWall registra y genera la telemetría.
Después:
nuestro SOC analiza los logs, el origen, la geolocalización, el proveedor, la frecuencia y el contexto.
Cuando corresponde, además, podemos relacionar la actividad con otras fuentes mediante SIEM Wazuh.
En GHM Soluciones Informáticas trabajamos con:
- firewalls SonicWall administrados;
- SIEM Wazuh;
- correlaciones personalizadas;
- Endpoint / EDR;
- Microsoft 365;
- monitorización SOC;
- hasta 400 días de histórico de logs.
Puede conocer nuestras soluciones de Endpoint y firewall para empresas y nuestro servicio de SIEM Wazuh para empresas.
Porque la pregunta no debería ser únicamente:
“¿Mi firewall está encendido?”
Debería ser:
“¿Quién revisa lo que está detectando y quién investiga cuando algo realmente merece atención?”
Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores de compromiso SonicWall
¿Cuántos indicadores de compromiso SonicWall se analizaron en la semana 36?
Nuestro SOC analizó 1.975 indicadores procedentes de firewalls SonicWall TZ270 y TZ370.
¿Significan 1.975 ataques?
No. Un indicador o evento no equivale automáticamente a un ataque ni a un compromiso confirmado.
¿Qué eventos se observaron?
Principalmente Port Scan Possible y SMTP Server on RBL Blacklist.
¿Qué es Port Scan Possible?
Es una detección compatible con actividad de escaneo de puertos. Puede corresponder a reconocimiento automatizado y no implica por sí sola que exista una intrusión.
¿Qué significa SMTP Server on RBL Blacklist?
Indica que un servidor SMTP observado aparece en una lista de reputación RBL. Es una señal reputacional, no una confirmación automática de malware.
¿De qué países procedía la actividad?
La infraestructura observada se distribuía entre diferentes regiones de Europa, Norteamérica y Asia.
¿Significa eso que los atacantes estaban físicamente en esos países?
No. La geolocalización suele indicar dónde está registrada o alojada la infraestructura, no necesariamente la ubicación de la persona que la utiliza.
¿Qué proveedores aparecieron asociados a parte de la infraestructura?
Entre los rangos analizados aparecen infraestructuras vinculadas a grandes plataformas cloud o de hosting como Google Cloud, Microsoft Azure, DigitalOcean y OVHcloud.
¿Eso significa que OVH, Google, Microsoft o DigitalOcean realizaron los ataques?
No. Son proveedores de infraestructura. Un tercero puede utilizar servidores o recursos alojados en sus redes.
¿Se bloquearon los 1.975 eventos?
No se debe afirmar eso sin revisar la acción concreta de cada registro. Algunos eventos pueden haber sido bloqueados, detectados o simplemente registrados según la política aplicada.
¿Un escaneo de puertos compromete el firewall?
No por sí solo. El riesgo depende de si existe un servicio accesible, vulnerable o incorrectamente configurado.
¿Por qué recibimos escaneos aunque seamos una pyme?
Porque gran parte del reconocimiento de Internet es automatizado y recorre rangos completos buscando servicios expuestos.
¿Qué aporta SIEM Wazuh?
Permite centralizar y correlacionar los logs del firewall con otras fuentes para facilitar investigaciones.
¿Qué aporta el SOC?
El SOC analiza el contexto para distinguir actividad normal, reconocimiento, comportamiento sospechoso y situaciones que requieren actuación.
¿Por qué conservar 400 días de logs?
Porque un incidente o un nuevo indicador puede conocerse meses después y puede ser necesario buscar retrospectivamente actividad relacionada.
¿Qué debería revisar una empresa en su firewall?
Firmware, reglas, VPN, usuarios, servicios publicados, copias de configuración, logs y vulnerabilidades.
¿Un firewall es suficiente para proteger una empresa?
No. Debe complementarse con Endpoint / EDR, MFA, copias, seguridad Microsoft 365, monitorización, SIEM y procedimientos adecuados.
¿Qué sectores pueden beneficiarse de un SonicWall administrado?
Administraciones de fincas, asesorías, despachos jurídicos, arquitectura, interiorismo, constructoras, ingeniería y otros despachos profesionales, siempre dimensionando el modelo y la configuración según cada infraestructura.
