Azure Web Application Firewall es un servicio nativo de nube que protege las aplicaciones web frente a técnicas comunes de pirateo web, como la inyección de código SQL, y vulnerabilidades de seguridad, como los scripts entre sitios. Implemente el servicio en cuestión de minutos para obtener una visibilidad completa de su entorno y bloquear los ataques malintencionados.
El monitoreo de Azure WAF se puede realizar a través de:
Azure Monitor
Azure Security Center (predeterminado)
Azure Sentinel ( Azure WAF Data Connector requiere la configuración de diagnóstico de Application Gateway para enviar los datos a Azure Sentinel Log Analytics )
En la siguiente entrada vamos a ver como montar una arquitectura de SFTP en Azure en alta disponibilidad.
Este tutorial no veremos en detalle como desplegar un servidor en azure, ni una vnet…etc por lo tanto se pasará un poco por encima en la creación de estos recursos.
Escenario
Para garantizar la alta disponibilidad del servicio disponemos de dos servidores GNU/Linux en diferentes zonas de disponibilidad.
Dicha alta disponibilidad cuenta con balanceo de carga entre los diferentes servidores mediante Azure Load Balancer, de la misma forma, para otorgar persistencia de los datos transferidos contamos con almacenamiento compartido entre los dos servidores empleando Azure File share
Para montar los recursos compartidos de Azure FIle Share se realizará mediante autofs, de esta forma garantizamos que los recursos únicamente se monten cuando sean necesarios.
Azure Active Directory Domain Services (Azure AD DS) proporciona servicios de dominio administrados como unión a un dominio, directiva de grupo, protocolo ligero de acceso a directorios (LDAP) y autenticación Kerberos o NTLM. Puede usar estos servicios de dominio sin necesidad de implementar o administrar los controladores de dominio de la nube, ni de aplicarles revisiones.
En esta ocasión veremos como crear reglas en Azure Sentinel para que cuando detecte o bloque algún ataque nos genere una alerta.
Para ello vamos a utilizar las siguientes querys:
Forti | where (FTNTFGTseverity == "critical" or FTNTFGTseverity == "high" and act == "detected" or act == "reset")
Forti | where (FTNTFGTseverity == "medium" or FTNTFGTseverity == "warning" and act == "detected" or act == "reset")
Forti | where (FTNTFGTseverity == "critical" or FTNTFGTseverity == "High" and act == "dropped" or act == "blocked")
Forti | where (FTNTFGTseverity == "medium" or FTNTFGTseverity == "warning" and act == "dropped" or act == "blocked")
Para que no se alargue excesivamente la entrada únicamente mostraré como se hace una regla. Pero debéis realizar una regla por cada query que os mostré en el punto anterior.
En la siguiente entrada seguimos viendo como montar nuestro entorno de Azure Sentinel desde cero.
En esta ocasión veremos como parsear los eventos que nos llegan desde Foritgate.
Si observamos como nos llega los eventos de parsear nos damos cuenta que realmente los eventos importantes se almacenan dentro de las dos columnas «SyslogMessage»
Anteriormente ya vimos como conectar diferentes recursos para obtener información de diferentes dispositivos, en este caso vamos a parsear los eventos que nos llega de Sysmon
Si observamos como nos llega los eventos de Sysmon nos damos cuenta que realmente los eventos importantes se almacenan dentro de las dos columnas «ParameterXml» y «EventData»:
En primer lugar, debemos configurar Fortinet para reenviar mensajes de Syslog en formato CEF (Por defecto ya lo envía en formato CEF) a nuestra área de trabajo de Azure a través del agente de Syslog (El reenviador configurado anteriormente).