Durante la semana 35 de 2026, nuestro SOC de GHM Soluciones Informáticas analizó 1.466 indicadores de compromiso SonicWall y eventos de interés registrados en firewalls SonicWall TZ270 y TZ370 instalados en diferentes infraestructuras empresariales.
La actividad revisada estuvo relacionada principalmente con dos tipologías:
- Port Scan Possible
- SMTP Server on RBL Blacklist
Además, el análisis de las fuentes de red muestra actividad procedente o alojada en diferentes regiones y grandes infraestructuras de Internet, incluyendo redes cloud y proveedores de hosting utilizados legítimamente por miles de empresas.
Este último punto es importante:
que una conexión proceda de un proveedor cloud o de un determinado país no significa que ese proveedor o país sea responsable de una actividad maliciosa.
Los atacantes, bots y sistemas automatizados también pueden utilizar servidores alquilados, VPS o servicios cloud de terceros.
Por eso no basta con mirar una dirección IP.
Hay que analizar evento + reputación + comportamiento + contexto + infraestructura afectada.
¿Qué son los indicadores de compromiso SonicWall?
Los indicadores de compromiso SonicWall son señales técnicas que pueden resultar útiles para identificar actividad potencialmente sospechosa.
Pueden estar relacionados con:
- direcciones IP;
- dominios;
- escaneos;
- reputación;
- conexiones;
- intentos de acceso;
- servidores incluidos en listas de reputación;
- patrones de tráfico.
Sin embargo, existe una diferencia fundamental:
un indicador no demuestra por sí solo que una empresa haya sido comprometida.
Puede representar un intento.
Puede ser reconocimiento automatizado.
Puede corresponder a un servidor con mala reputación.
O puede formar parte de actividad legítima que necesita contexto.
Por eso nuestro SOC analiza los logs registrados por SonicWall antes de determinar su relevancia.
1.466 indicadores analizados durante una semana
Los firewalls SonicWall TZ270 y TZ370 incluidos en la supervisión registraron durante la semana 1.466 indicadores y eventos asociados a las reglas analizadas por nuestro SOC.
Este volumen vuelve a mostrar una realidad cotidiana de Internet:
una conexión empresarial pública recibe continuamente tráfico que no ha solicitado.
Bots y sistemas automatizados recorren Internet buscando:
- puertos abiertos;
- servidores;
- VPN;
- correo electrónico;
- interfaces web;
- dispositivos de red;
- servicios vulnerables.
Esto no significa necesariamente que alguien haya seleccionado manualmente a esa empresa.
Gran parte de esa actividad es automática.
Indicadores de compromiso SonicWall: ¿desde dónde apareció la actividad?
En lugar de publicar las direcciones IP concretas —algo que no resulta necesario para explicar el riesgo— hemos agrupado la información según las redes observadas.
Entre los indicadores aparecen infraestructuras relacionadas con grandes proveedores de cloud, VPS y hosting, incluyendo redes pertenecientes o asociadas a plataformas como:
- Microsoft Azure
- Google Cloud
- DigitalOcean
- Akamai / Linode
- proveedores europeos de hosting y centros de datos
- redes de telecomunicaciones y alojamiento de otras regiones
La geolocalización de las infraestructuras observadas se distribuye principalmente entre:
Norteamérica, Europa y Asia.
Entre los países asociados a las redes analizadas aparecen ubicaciones en Estados Unidos, Alemania, Reino Unido y diferentes países asiáticos, entre otras localizaciones.
Esta información debe interpretarse con prudencia.
La geolocalización de una IP no identifica al atacante
Supongamos que una conexión aparece geolocalizada en Estados Unidos.
Eso no significa que el atacante esté físicamente en Estados Unidos.
El origen visible puede ser:
- un VPS;
- una máquina comprometida;
- un servidor cloud;
- una VPN;
- un proxy;
- infraestructura alquilada.
Por ejemplo, una persona situada en cualquier parte del mundo puede contratar en minutos un servidor virtual alojado en otro país.
Por eso nuestro SOC no interpreta:
“IP alemana = atacante alemán”.
La interpretación correcta sería:
“la actividad ha llegado desde una dirección perteneciente o geolocalizada en una infraestructura asociada a esa región”.
Esta diferencia es importante cuando se realiza análisis de seguridad profesional.
El hosting no es el atacante
También es importante evitar otro error frecuente.
Entre los indicadores pueden aparecer direcciones alojadas en grandes plataformas de infraestructura.
Por ejemplo:
Microsoft Azure
Google Cloud
DigitalOcean
Akamai / Linode
La presencia de estas redes en un evento de seguridad no implica que Microsoft, Google, DigitalOcean o Akamai estén realizando un ataque.
Estas compañías proporcionan infraestructura a millones de clientes.
Un tercero puede contratar un servidor y utilizarlo para:
- alojar una web;
- ejecutar aplicaciones;
- realizar pruebas;
- automatizar tareas;
- escanear Internet;
- desarrollar actividad abusiva.
Por eso el proveedor únicamente nos aporta contexto sobre la infraestructura desde la que se observa la conexión.
Indicadores de compromiso SonicWall y Port Scan Possible
Una de las principales categorías registradas durante la semana fue:
Port Scan Possible
Un escaneo de puertos intenta determinar qué servicios están accesibles en una dirección de Internet.
Por ejemplo, un sistema puede probar:
22 → SSH
25 → SMTP
80 → HTTP
443 → HTTPS
3389 → RDP
u otros puertos.
El objetivo puede ser conocer qué servicios existen antes de intentar interactuar con ellos.
¿Un Port Scan Possible significa que han entrado en la empresa?
No.
Este punto es especialmente importante.
Detectar un escaneo no significa detectar una intrusión.
Podemos imaginarlo como alguien comprobando qué puertas tiene un edificio.
Una cosa es:
comprobar si existe una puerta.
Otra muy diferente:
conseguir abrirla.
Por eso un Port Scan Possible representa una señal de reconocimiento o comportamiento compatible con un escaneo que debe contextualizarse.
No demuestra por sí solo que el firewall haya sido superado.
¿Por qué se escanean continuamente las IP públicas?
Porque Internet puede automatizarse.
Existen herramientas capaces de recorrer enormes rangos de direcciones buscando servicios concretos.
Los objetivos pueden ser diferentes:
- investigación;
- inventarios;
- motores de búsqueda de Internet;
- reconocimiento legítimo;
- bots;
- cibercriminales;
- sistemas comprometidos.
Cuando aparece una vulnerabilidad nueva, los escaneos pueden buscar rápidamente dispositivos que expongan el servicio afectado.
Por eso resulta tan importante reducir la superficie publicada.
Menos servicios expuestos, menor superficie de ataque
Una regla sencilla:
si un servicio no necesita estar accesible desde Internet, no debería estar publicado.
Esto resulta especialmente relevante para:
- RDP;
- SSH;
- administración de NAS;
- paneles administrativos;
- cámaras;
- servidores;
- aplicaciones internas.
Cuando necesitamos acceso remoto, es preferible utilizar mecanismos diseñados específicamente para ello.
Por ejemplo:
VPN segura + autenticación + control de acceso
en lugar de publicar directamente servicios internos.
Indicadores de compromiso SonicWall y VPN
Las VPN empresariales permiten acceder desde el exterior a recursos internos.
Sin embargo, también deben mantenerse correctamente administradas.
Conviene revisar:
- usuarios;
- contraseñas;
- MFA cuando esté disponible;
- firmware;
- permisos;
- registros;
- cuentas antiguas.
Un usuario que dejó la empresa hace meses no debería seguir conservando acceso VPN.
Y una cuenta que solo necesita acceder a un servidor no debería poder acceder automáticamente a toda la red.
Segundo evento: SMTP Server on RBL Blacklist
La otra categoría registrada esta semana fue:
SMTP Server on RBL Blacklist
RBL significa generalmente Real-time Blackhole List o lista de reputación/bloqueo.
Estas listas contienen direcciones asociadas a determinados comportamientos relacionados con correo electrónico.
Por ejemplo:
- spam;
- abuso;
- servidores comprometidos;
- configuraciones incorrectas;
- infraestructura con mala reputación.
Cuando SonicWall identifica actividad SMTP relacionada con una dirección incluida en una de estas listas, genera un evento que puede ser revisado.
¿SMTP Server on RBL Blacklist significa malware?
No necesariamente.
Significa que el servidor SMTP implicado aparece en una lista de reputación utilizada para combatir correo no deseado o abusivo.
Puede ocurrir porque:
- envió spam;
- fue comprometido;
- comparte infraestructura;
- tuvo una configuración incorrecta;
- heredó reputación negativa de una IP.
Por tanto, nuevamente:
alerta ≠ infección confirmada.
Nuestro SOC analiza el contexto antes de determinar si existe algún impacto para la empresa supervisada.
¿Y si SonicWall no bloquea uno de estos eventos?
No todos los eventos registrados por un firewall representan tráfico que deba bloquearse automáticamente.
Un firewall también:
- observa;
- registra;
- clasifica;
- aplica reglas;
- genera alertas.
El tratamiento depende de:
- tipo de evento;
- dirección del tráfico;
- política configurada;
- servicio;
- reputación;
- contexto.
Por eso sería incorrecto afirmar que los 1.466 indicadores fueron 1.466 ataques bloqueados.
Lo que podemos afirmar es que:
SonicWall generó los eventos y nuestro SOC analizó los logs asociados para determinar su contexto y relevancia.
Cuando una actividad requiere actuación, puede ser necesario:
- bloquear una dirección;
- modificar una regla;
- revisar un servidor;
- investigar un endpoint;
- comprobar una VPN;
- revisar otra fuente de telemetría.
Un firewall no solamente bloquea
El firewall desempeña varias funciones.
Puede:
🔥 aplicar políticas de seguridad
🌐 controlar comunicaciones
🔐 proporcionar VPN
🧩 separar redes
📊 generar logs
🚨 identificar determinados comportamientos
Pero el firewall no conoce siempre todo el contexto empresarial.
Puede detectar:
“posible escaneo”.
Sin embargo, para entender completamente la situación quizá necesitemos también información de:
- Windows;
- servidor;
- antivirus;
- Microsoft 365;
- SIEM.
Por eso trabajamos con seguridad por capas.
SonicWall registra. Nuestro SOC analiza.
Esta distinción es fundamental.
SonicWall detecta y registra eventos.
Después:
nuestro SOC analiza los logs, revisa su contexto y determina si la actividad es legítima, sospechosa o necesita actuación.
No se trata simplemente de instalar un firewall.
Se trata de administrarlo y supervisarlo continuamente.
Indicadores de compromiso SonicWall y SIEM Wazuh
Los logs de firewall pueden integrarse en una plataforma SIEM Wazuh.
Esto permite centralizar información junto con otras fuentes.
Por ejemplo:
SonicWall
registra una conexión.
Windows
registra actividad en el endpoint.
Kaspersky / EDR
detecta comportamiento.
Microsoft 365
registra una autenticación.
Wazuh
permite centralizar y correlacionar esas señales.
Después nuestro SOC analiza el contexto.
Puede conocer más sobre nuestro servicio de SIEM Wazuh para empresas.
La correlación puede cambiar completamente el contexto
Imaginemos este escenario.
Evento 1
El firewall registra una conexión desde una infraestructura sospechosa.
Por sí sola quizá no sea especialmente significativa.
Evento 2
Un endpoint registra un inicio de sesión extraño.
Ahora tenemos una segunda señal.
Evento 3
El antivirus genera una detección.
En ese momento, tres acontecimientos que individualmente podían tener poca información pueden formar parte de una misma investigación.
Ahí es donde la correlación entre fuentes aporta valor.
Indicadores personalizados para cada infraestructura
No todas las empresas necesitan exactamente las mismas reglas.
Una asesoría puede depender fundamentalmente de:
- Microsoft 365;
- aplicaciones de gestión;
- servidores;
- certificados.
Una ingeniería puede utilizar:
- NAS;
- VPN;
- servidores;
- grandes repositorios de proyectos.
Una administración de fincas puede depender de:
- Microsoft 365;
- banca;
- aplicaciones verticales;
- documentación.
Por eso las correlaciones deben adaptarse al entorno.
400 días de logs para poder volver atrás
En nuestros servicios conservamos hasta 400 días de registros.
Esta retención permite realizar búsquedas históricas cuando aparece una incidencia.
Supongamos que hoy encontramos un indicador importante.
Podemos preguntarnos:
¿Ya apareció hace seis meses?
¿Hubo conexiones anteriores desde la misma infraestructura?
¿Qué ocurrió aquel día?
¿Hubo actividad relacionada en un endpoint?
Cuanto mayor sea el histórico disponible, mayor capacidad tendremos para investigar el pasado.
Indicadores de compromiso SonicWall e investigaciones posteriores
Un incidente no siempre se descubre el mismo día que comienza.
Por ejemplo:
Hoy detectamos una cuenta comprometida.
Entonces necesitamos revisar:
ayer
la semana pasada
hace tres meses
Si el histórico ya fue eliminado, hemos perdido parte de la evidencia.
Por eso almacenar logs no solamente sirve para mirar alertas en tiempo real.
También sirve para:
- investigaciones;
- auditorías;
- análisis forense;
- reconstrucción de incidentes.
¿Por qué 400 días?
Un periodo amplio permite cubrir más de un año de actividad.
Esto puede resultar especialmente útil cuando:
- una intrusión se descubre tarde;
- se realiza una auditoría;
- aparece un nuevo indicador;
- necesitamos comparar comportamientos;
- investigamos actividad anterior.
No significa que cada registro vaya a ser revisado manualmente.
Significa que la evidencia continúa disponible cuando necesitamos buscarla.
Indicadores de compromiso SonicWall en administraciones de fincas
Las administraciones de fincas son uno de los entornos donde administramos este tipo de firewall.
Habitualmente trabajan con:
- información de propietarios;
- cuentas bancarias;
- documentación;
- proveedores;
- Microsoft 365;
- certificados digitales.
Por tanto, la conectividad y protección perimetral son elementos críticos.
Una incidencia puede afectar tanto a la seguridad como a la continuidad de la oficina.
Asesorías contables y laborales
Las asesorías gestionan información especialmente sensible.
Por ejemplo:
- nóminas;
- documentación fiscal;
- DNI;
- cuentas bancarias;
- contratos.
También interactúan constantemente con organismos públicos y clientes.
Por eso necesitan combinar:
- firewall;
- Endpoint / EDR;
- MFA;
- copias;
- actualizaciones;
- monitorización.
Despachos de abogados
Los despachos jurídicos manejan información confidencial por naturaleza.
Además, pueden utilizar:
- Microsoft 365;
- servidores;
- NAS;
- VPN;
- teletrabajo.
Una correcta configuración perimetral ayuda a reducir servicios innecesariamente expuestos y controlar el acceso remoto.
Arquitectura e interiorismo
Estos sectores suelen trabajar con:
- proyectos;
- planos;
- imágenes;
- NAS;
- software técnico;
- Microsoft 365;
- acceso remoto.
Una VPN correctamente configurada puede ser esencial para el teletrabajo.
Además, separar mediante VLAN determinados dispositivos puede reducir la superficie de comunicación interna.
Constructoras y desarrollos de ingeniería
Las constructoras e ingenierías pueden combinar:
- oficina;
- sedes;
- trabajadores remotos;
- NAS;
- servidores;
- aplicaciones técnicas.
Por ello, el firewall no debe considerarse únicamente como el dispositivo que proporciona conexión a Internet.
Es una pieza de la arquitectura de seguridad.
Despachos profesionales ubicados en viviendas
Una oficina ubicada en una vivienda puede gestionar información tan sensible como una empresa situada en un edificio corporativo.
La ubicación física no determina el nivel de riesgo.
Un abogado, arquitecto, asesor o ingeniero puede almacenar desde su despacho:
- información personal;
- documentación empresarial;
- certificados;
- proyectos.
Por tanto, también necesita medidas de seguridad adecuadas.
Indicadores de compromiso SonicWall y segmentación mediante VLAN
Una buena estrategia no termina en el perímetro.
También debemos pensar:
¿Qué ocurre si un dispositivo interno resulta comprometido?
En una red completamente plana puede intentar comunicarse con otros equipos.
La segmentación permite separar:
- empleados;
- servidores;
- invitados;
- cámaras;
- IoT;
- dispositivos de gestión.
Después el firewall controla qué comunicaciones se permiten entre segmentos.
Una cámara no necesita hablar con toda la empresa
Este ejemplo permite entender fácilmente la segmentación.
Una cámara de seguridad quizá necesite comunicarse con:
- grabador;
- NVR;
- determinados servicios.
Pero probablemente no necesita acceder directamente a:
- ordenadores de administración;
- servidores de archivos;
- impresoras;
- portátiles.
Por eso crear redes diferenciadas puede reducir el impacto de un problema.
WiFi de invitados también debería estar separado
El mismo principio se aplica a visitantes.
Un invitado necesita:
Internet.
Normalmente no necesita:
servidores + NAS + impresoras + equipos corporativos.
Por eso una red de invitados bien diseñada debe mantenerse aislada.
La segmentación añade otra capa incluso aunque el firewall perimetral esté correctamente configurado.
Indicadores de compromiso SonicWall y mantenimiento del firewall
Un firewall necesita mantenimiento durante toda su vida útil.
Eso incluye:
- firmware;
- reglas;
- VPN;
- usuarios;
- objetos;
- certificados;
- servicios publicados;
- logs.
Con el tiempo aparecen configuraciones obsoletas.
Por ejemplo:
regla creada para una aplicación que ya no existe.
Si nadie la revisa, puede permanecer años.
Por eso un firewall administrado es diferente de un firewall simplemente instalado.
Firewall instalado frente a firewall administrado
Podemos resumirlo así:
Firewall instalado
Está conectado.
Internet funciona.
Las reglas iniciales están configuradas.
Firewall administrado
Además:
- se actualiza;
- se revisan reglas;
- se controlan VPN;
- se supervisan eventos;
- se revisan accesos;
- se mantienen copias;
- se analizan logs.
Desde una perspectiva de seguridad, la diferencia es considerable.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
El firewall tampoco sustituye al Endpoint / EDR
Un firewall observa principalmente comunicaciones.
Pero quizá no conozca qué proceso generó una conexión.
Ahí entra la protección endpoint.
Por ejemplo:
SonicWall puede registrar:
equipo → dirección externa
Endpoint / EDR puede aportar:
proceso → archivo → usuario
Al combinar ambas fuentes obtenemos más contexto.
Tampoco sustituye a Microsoft 365
Muchas empresas ya almacenan gran parte de su información fuera de la red local.
Por ejemplo:
- correo;
- SharePoint;
- OneDrive;
- Teams.
Un firewall no puede explicar por sí solo todo lo que ocurre dentro de Microsoft 365.
Por eso también supervisamos los registros cloud cuando la infraestructura lo requiere.
Indicadores de compromiso SonicWall y seguridad por capas
Una estrategia empresarial debería combinar diferentes controles.
Perímetro
Firewall.
Red
VLAN y reglas.
Identidad
MFA y Acceso Condicional.
Endpoint
Antivirus / EDR.
Datos
Copias y permisos.
Visibilidad
SIEM.
Análisis
SOC.
No existe una única herramienta capaz de sustituir todo lo anterior.
1.466 indicadores: ¿es mucho o poco?
El número por sí solo no permite determinar el nivel de riesgo.
Una semana puede tener:
500 indicadores
y contener uno especialmente relevante.
Otra puede tener:
5.000
formados principalmente por escaneos automatizados.
Por eso nuestro objetivo no es generar un número espectacular.
Nuestro objetivo es responder:
¿qué significan esos eventos para la infraestructura protegida?
Los indicadores necesitan contexto
Cuando analizamos un evento revisamos factores como:
- origen;
- destino;
- servicio;
- comportamiento;
- reputación;
- momento;
- recurrencia;
- relación con otros logs.
También podemos comprobar si el origen está asociado a:
- cloud;
- hosting;
- telecomunicaciones;
- redes residenciales.
Pero esa información es contexto.
No una conclusión automática.
Un proveedor cloud puede aparecer en cientos de incidentes legítimos y maliciosos
Las grandes plataformas alojan millones de servicios.
Por eso bloquear completamente:
Microsoft Azure
Google Cloud
DigitalOcean
o cualquier gran proveedor únicamente porque una IP haya generado actividad sospechosa sería normalmente una mala estrategia.
Podríamos bloquear también:
- aplicaciones legítimas;
- webs;
- servicios empresariales.
Las medidas deben ser específicas y proporcionadas.
Indicadores de compromiso SonicWall y falsos positivos
Cualquier sistema de detección puede producir eventos que posteriormente resulten legítimos.
Por eso ajustar reglas es una parte importante de la monitorización.
El objetivo no es:
generar el mayor número posible de alertas.
El objetivo es:
detectar las señales que realmente merecen atención.
Una plataforma que produce miles de falsas alarmas puede acabar ocultando los eventos importantes.
Nuestro SOC analiza antes de comunicar
Cuando una regla detecta actividad:
- se recibe el evento;
- se revisa el contexto;
- se buscan evidencias adicionales;
- se comprueba si existen correlaciones;
- se determina si requiere actuación.
Así reducimos el ruido.
Además, cuando existe una incidencia real, el cliente recibe una comunicación con mayor contexto.
Monitorización continua de SonicWall TZ270 y TZ370
Los modelos SonicWall TZ270 y TZ370 están orientados a entornos empresariales y permiten implementar diferentes capas de protección perimetral.
En nuestras infraestructuras administradas forman parte de una estrategia que puede incluir:
- actualización;
- VPN;
- segmentación;
- monitorización;
- logs;
- SIEM;
- SOC.
La tecnología es importante.
Pero la administración continua es lo que permite mantenerla adaptada a la realidad de la empresa.
¿Qué debería revisar una pyme en su firewall?
Podemos empezar por unas preguntas sencillas:
¿Está actualizado?
¿Quién lo administra?
¿Qué servicios están publicados?
¿Qué usuarios VPN existen?
¿Se utilizan cuentas antiguas?
¿La red está segmentada?
¿Se almacenan logs?
¿Quién analiza las alertas?
Si algunas respuestas son desconocidas, existe margen para mejorar la seguridad.
Indicadores de compromiso SonicWall: principales conclusiones de la semana 35
Durante la semana 35 de 2026:
1.466 indicadores y eventos de interés fueron analizados por nuestro SOC.
Las principales categorías fueron:
Port Scan Possible
y
SMTP Server on RBL Blacklist.
La infraestructura de origen observada incluyó redes de diferentes regiones y proveedores cloud/hosting.
Sin embargo:
no atribuimos esas conexiones a los proveedores ni utilizamos la geolocalización como prueba de la ubicación de un atacante.
El análisis se centra en el comportamiento y en su relación con la infraestructura protegida.
Conclusión: indicadores de compromiso SonicWall necesitan análisis, no solamente alertas
Durante la semana 35 de 2026, nuestro SOC analizó 1.466 indicadores de compromiso SonicWall y eventos relacionados registrados en firewalls TZ270 y TZ370 administrados en diferentes sectores profesionales.
La actividad se concentró principalmente en:
🔎 posibles escaneos de puertos
📧 servidores SMTP asociados a listas RBL
También observamos tráfico asociado a diferentes redes cloud, VPS y hosting distribuidas entre Norteamérica, Europa y Asia.
Pero un dato de geolocalización o un proveedor de alojamiento no identifica al responsable de una actividad.
Por eso:
SonicWall registra el evento.
Nuestro SOC analiza los logs y su contexto.
Además, integramos la información relevante dentro de nuestra estrategia de ciberseguridad empresarial y SIEM Wazuh para empresas, manteniendo hasta 400 días de histórico de logs para facilitar investigaciones y auditorías posteriores.
Firewall, Endpoint / EDR, Microsoft 365, segmentación, SIEM y SOC cumplen funciones diferentes.
Juntos proporcionan una visión mucho más completa de lo que ocurre en una infraestructura.
La pregunta para una empresa no debería ser únicamente:
“¿Tengo firewall?”
La pregunta realmente importante es:
“¿Quién lo actualiza, quién revisa sus alertas y quién investiga lo que ocurre cuando aparece una señal sospechosa?”
Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores de compromiso SonicWall
¿Cuántos indicadores de compromiso SonicWall se analizaron en la semana 35?
Nuestro SOC analizó 1.466 indicadores y eventos de interés procedentes de firewalls SonicWall TZ270 y TZ370 durante la semana 35 de 2026.
¿Qué eventos fueron los más destacados?
Principalmente Port Scan Possible y SMTP Server on RBL Blacklist.
¿Qué significa Port Scan Possible?
Es un evento compatible con un posible escaneo destinado a identificar puertos o servicios accesibles. Por sí solo no demuestra que haya existido una intrusión.
¿Un escaneo de puertos significa que han hackeado la empresa?
No. Puede representar una fase de reconocimiento automatizado. Es necesario analizar si posteriormente existe otra actividad relacionada.
¿Qué significa SMTP Server on RBL Blacklist?
Indica que una dirección relacionada con un servidor SMTP aparece en una lista de reputación o bloqueo utilizada habitualmente para detectar fuentes vinculadas a spam o abuso.
¿Eso significa que el servidor contiene malware?
No necesariamente. La inclusión en una RBL puede tener diferentes causas y debe analizarse dentro de su contexto.
¿De qué países procedía la actividad observada?
Las redes analizadas se distribuyeron entre diferentes regiones de Norteamérica, Europa y Asia, incluyendo infraestructuras geolocalizadas en Estados Unidos, Alemania, Reino Unido y países asiáticos, entre otras localizaciones.
¿Aparecieron proveedores cloud o hosting?
Sí. Entre las redes observadas existen infraestructuras pertenecientes o relacionadas con grandes proveedores de cloud, VPS y centros de datos, incluyendo Microsoft Azure, Google Cloud, DigitalOcean y Akamai/Linode.
¿Eso significa que esos proveedores realizaron los ataques?
No. Son proveedores de infraestructura utilizados por numerosos clientes. Una IP alojada en una determinada plataforma no identifica a la persona u organización que está utilizando el servidor.
¿La geolocalización identifica al atacante?
No. Indica aproximadamente dónde está registrada o ubicada la infraestructura visible. El usuario real puede estar en cualquier otro país.
¿Se bloquearon los 1.466 indicadores?
No debemos interpretar esa cifra como 1.466 ataques bloqueados. Los eventos pueden tener diferentes acciones y contextos. SonicWall los registra y nuestro SOC analiza cuáles requieren investigación o actuación.
¿Qué diferencia existe entre SonicWall y el SOC?
SonicWall detecta y registra determinados eventos de red. Nuestro SOC analiza esos logs y su contexto para determinar si representan actividad legítima, sospechosa o una situación que requiere actuación.
¿Por qué integrar SonicWall con Wazuh?
Porque permite centralizar registros y relacionarlos con otras fuentes, como Windows, Microsoft 365, antivirus o servidores.
¿Qué ventajas ofrecen las correlaciones?
Permiten comprobar si diferentes señales comparten elementos como IP, usuario, equipo o momento temporal, aportando más contexto que un evento aislado.
¿Por qué conservar 400 días de logs?
Porque algunos incidentes se descubren meses después. El histórico permite buscar actividad anterior y conservar evidencia para investigaciones y auditorías.
¿Qué sectores utilizan estos firewalls?
Entre las infraestructuras gestionadas se encuentran administraciones de fincas, asesorías contables y laborales, despachos de abogados, arquitectura, interiorismo, constructoras, ingeniería y despachos profesionales.
¿Un firewall es suficiente para proteger una empresa?
No. Debe combinarse con actualización, Endpoint / EDR, MFA, segmentación, copias, monitorización, SIEM y análisis SOC según las necesidades de cada infraestructura.
¿Qué debería revisar una empresa en su firewall?
Firmware, servicios expuestos, VPN, usuarios, reglas, segmentación, logs y quién se encarga de analizar las alertas.
