Buenas tardes noders,
Hace mucho tiempo que no subo contenido relacionado al ámbito del foro y ya era hora,
¿Qué es un Firewall?
Bien, la respuesta a mi juicio más acertada sería la de un dispositivo administrado por los técnicos de una red diseñado para aceptar/denegar tráfico, así en bruto, pero podemos desglosarlo más.
Tráfico lícito
Es aquel tráfico que necesitamos para que nuestra organización pueda funcionar, por ejemplo, hay empresas que tienen sus propias aplicaciones internas para funcionar como es normal. Hay aplicaciones de escritorio que te las instalan en la maqueta de tu PC corporativo y que se ejecutan en el propio PC (clientes pesados) y otras a las que accedemos para poder utilizarlas (clientes ligeros).
Todas esas aplicaciones tienen una serie de puertos que deben de estar habilitados para poder correr, entonces pensaréis que el administrador de red de la empresa tiene que habilitarlos para poder funcionar, pero no es tan sencillo, la BBDD (Base de Datos) donde se almacenan la información de los trabajadores, sus nóminas... etc en principio por ley de protección de datos no deberían de estar visibles para por ejemplo, el propio departamento de IT, porque no sería normal que yo pudiese visualizar lo que cobra mi compañero, entonces es cuando empezamos a segmentar la red.
Declaramos una subred para los equipos de RRHH, el departamento que gestione los Servidores de los aplicativos de RRHH configurarán la IP en sus servidores, y cuando se haya esquematizado la red, nosotros como administradores del FW (Firewall) daremos solo acceso desde la DMZ donde están ubicados esos servidores a la subred de RRHH. Eso si es tráfico lícito, el tráfico ilícito no es siempre el tráfico desde fuera hacia dentro, dentro de la misma red corporativa existe tráfico ilícito.
Es importante hacer este tipo de segmentaciones, porque imaginémonos que carecemos de ello, un atacante mediante un phising consigue las claves de acceso de un trabajador de nuestra empresa. Si no tuviesemos segmentada la red y separado el tráfico según departamento, ese atacante podría llegar a acceder hasta la cocina como quien dice.
Un FW no protege de ataques, a priori - hay fabricantes que si incluyen una capa de inteligencia en sus FW, pero son licencias que se pagan a parte-, por lo que si dicho atacante se salta ese primer bloqueo perimetral al poder acceder desde un equipo del interior, el atacante ya no es exterior, sino que está dentro de nuestra propia red.
Eso también ayuda a los equipos de Blue Team a solucionar el problema, creando reglas de emergencia que vayan acorralando al atacante hasta localizar el foco de las conexiones y poder echarle de la red, poner el equipo en cuarentena y que un equipo forense estudie el por qué del ataque y aplicar las soluciones correctas para evitar un nuevo ataque.
También puede ser un gusano que se replique, un ransomware... etc, tuvimos un cliente muy importante que se coló un gusano en sus sistemas, y gracias que se detectó a tiempo y tener bien segmentada la red, se focalizó rápido la subred donde se origino el ataque. El ataque en cuestión consistió en un gusano que realizaba un broadcast a los equipos de la red, se conectaba a ellos, se descargaba los ficheros que podía y los enviaba a un punto exterior de la red donde los estaba recopilando. Gracias a tener una buena arquitectura de red, pudimos cortar las conexiones primero de ese departamento para que no pase al resto, lo que es poner en cuarentena la subred, y de ahí mediante el envío de paquetes poder localizar poco a poco a donde se estaba enviando toda esa información. Pensaréis, joder, corta las comunicaciones con el exterior para que no envíe datos. Si se podría haber hecho pero no hubiésemos aprendido nada del ataque, hay veces que es necesario dejar actuar para comprender el funcionamiento del ataque y la lógica detrás de este. Bien con la subred en cuarentena, fuimos acorralando poco a poco al gusano, y el departamente de forense pudo dictaminar que fue por un malware que se ejecutó en una macro de Excel.
Como veréis, hay ocasiones en que el tráfico lícito no es el propio tráfico interno, pues no tiene por qué ser una fuente lícita quien lo origine.
Tráfico ilícito
Este entiendo que es más fácil de interpretar, aquello que está mal, pero no. No es tan fácil, en el sentido de que hay conexiones que pueda realizar el Red Team en caja blanca para poder realizar un test de rendimiento y repsuesta ante incidentes.
En efecto, hay que capar entradas del exterior a DMZ y segmentos internos de la red corporativa, pero por ejemplo, tenemos un cliente que se conecta a un servico que ofrece mi empresa, por ejemplo, una empresa de transporte que tiene clientes que se conectan a través de una API para realizar los envíos, en principio la red corporativa de su cliente no es la de la propia empresa de transporte, es tráfico externo, pero que sí es lícito.
Hay que tener todas estas cosas en cuenta a la hora de administrar un FW.
Podría explayarme un poco más, pero tampoco creo que sea necesario hacerlo ahora.
Lo que tenéis que tener claro también a la hora de configurar y administrar un FW es que las políticas se ejecutan en orden. Por ejemplo, llega una petición desde la 10.0.0.1/32 por el puerto 8080 al servidor 10.1.0.254/32, pues bien, la petición va a ver si la primera política configurada permite el tráfico, si lo hace lo deja pasar y ahí se terminó, pero si no es el caso pasará a la siguiente política y así sucesivamente hasta la última, la última siempre tiene que ser un ANY ANY ANY DENY, porque sino que gracia, no se bloquearía nada.
Antes había dos filosofías, denegar todo por defecto e ir aceptando tráfico o la de aceptar todo por defecto e ir denegando tráfico, por seguridad ahora en España solo es legal la primera, porque en caso de fallo, el tráfico está denegado.
Eso no significa que no realices políticas de bloqueo más precisas, por ejemplo, sabemos la lista de IPs de Emotet, se pueden añadir a una política de Lista Negra arriba para que según entre una petición o salga una petición hacia esos servidores maliciosos, se elimine, y mejorar el rendimiento del FW y hacer que consuma menos recursos, porque no tendrá que matchear política a política hasta el final, lo que ahorrará tiempo y recursos del FW.
Así a brote pronto voy a dejar esto así, si veo que os mola y queréis que os cuente más sobre esta tecnología, decídmelo y lo continuaré, esto quiero solo que sea como un pequeño artículo para que entendáis SUPERFICIALMENTE y de forma generalizada como funciona un FW y como se administra, buenas praxis... etc
Hace mucho tiempo que no subo contenido relacionado al ámbito del foro y ya era hora,
¿Qué es un Firewall?
Bien, la respuesta a mi juicio más acertada sería la de un dispositivo administrado por los técnicos de una red diseñado para aceptar/denegar tráfico, así en bruto, pero podemos desglosarlo más.
Es aquel tráfico que necesitamos para que nuestra organización pueda funcionar, por ejemplo, hay empresas que tienen sus propias aplicaciones internas para funcionar como es normal. Hay aplicaciones de escritorio que te las instalan en la maqueta de tu PC corporativo y que se ejecutan en el propio PC (clientes pesados) y otras a las que accedemos para poder utilizarlas (clientes ligeros).
Todas esas aplicaciones tienen una serie de puertos que deben de estar habilitados para poder correr, entonces pensaréis que el administrador de red de la empresa tiene que habilitarlos para poder funcionar, pero no es tan sencillo, la BBDD (Base de Datos) donde se almacenan la información de los trabajadores, sus nóminas... etc en principio por ley de protección de datos no deberían de estar visibles para por ejemplo, el propio departamento de IT, porque no sería normal que yo pudiese visualizar lo que cobra mi compañero, entonces es cuando empezamos a segmentar la red.
Declaramos una subred para los equipos de RRHH, el departamento que gestione los Servidores de los aplicativos de RRHH configurarán la IP en sus servidores, y cuando se haya esquematizado la red, nosotros como administradores del FW (Firewall) daremos solo acceso desde la DMZ donde están ubicados esos servidores a la subred de RRHH. Eso si es tráfico lícito, el tráfico ilícito no es siempre el tráfico desde fuera hacia dentro, dentro de la misma red corporativa existe tráfico ilícito.
Es importante hacer este tipo de segmentaciones, porque imaginémonos que carecemos de ello, un atacante mediante un phising consigue las claves de acceso de un trabajador de nuestra empresa. Si no tuviesemos segmentada la red y separado el tráfico según departamento, ese atacante podría llegar a acceder hasta la cocina como quien dice.
Un FW no protege de ataques, a priori - hay fabricantes que si incluyen una capa de inteligencia en sus FW, pero son licencias que se pagan a parte-, por lo que si dicho atacante se salta ese primer bloqueo perimetral al poder acceder desde un equipo del interior, el atacante ya no es exterior, sino que está dentro de nuestra propia red.
Eso también ayuda a los equipos de Blue Team a solucionar el problema, creando reglas de emergencia que vayan acorralando al atacante hasta localizar el foco de las conexiones y poder echarle de la red, poner el equipo en cuarentena y que un equipo forense estudie el por qué del ataque y aplicar las soluciones correctas para evitar un nuevo ataque.
También puede ser un gusano que se replique, un ransomware... etc, tuvimos un cliente muy importante que se coló un gusano en sus sistemas, y gracias que se detectó a tiempo y tener bien segmentada la red, se focalizó rápido la subred donde se origino el ataque. El ataque en cuestión consistió en un gusano que realizaba un broadcast a los equipos de la red, se conectaba a ellos, se descargaba los ficheros que podía y los enviaba a un punto exterior de la red donde los estaba recopilando. Gracias a tener una buena arquitectura de red, pudimos cortar las conexiones primero de ese departamento para que no pase al resto, lo que es poner en cuarentena la subred, y de ahí mediante el envío de paquetes poder localizar poco a poco a donde se estaba enviando toda esa información. Pensaréis, joder, corta las comunicaciones con el exterior para que no envíe datos. Si se podría haber hecho pero no hubiésemos aprendido nada del ataque, hay veces que es necesario dejar actuar para comprender el funcionamiento del ataque y la lógica detrás de este. Bien con la subred en cuarentena, fuimos acorralando poco a poco al gusano, y el departamente de forense pudo dictaminar que fue por un malware que se ejecutó en una macro de Excel.
Como veréis, hay ocasiones en que el tráfico lícito no es el propio tráfico interno, pues no tiene por qué ser una fuente lícita quien lo origine.
Tráfico ilícito
Este entiendo que es más fácil de interpretar, aquello que está mal, pero no. No es tan fácil, en el sentido de que hay conexiones que pueda realizar el Red Team en caja blanca para poder realizar un test de rendimiento y repsuesta ante incidentes.
En efecto, hay que capar entradas del exterior a DMZ y segmentos internos de la red corporativa, pero por ejemplo, tenemos un cliente que se conecta a un servico que ofrece mi empresa, por ejemplo, una empresa de transporte que tiene clientes que se conectan a través de una API para realizar los envíos, en principio la red corporativa de su cliente no es la de la propia empresa de transporte, es tráfico externo, pero que sí es lícito.
Hay que tener todas estas cosas en cuenta a la hora de administrar un FW.
Podría explayarme un poco más, pero tampoco creo que sea necesario hacerlo ahora.
Lo que tenéis que tener claro también a la hora de configurar y administrar un FW es que las políticas se ejecutan en orden. Por ejemplo, llega una petición desde la 10.0.0.1/32 por el puerto 8080 al servidor 10.1.0.254/32, pues bien, la petición va a ver si la primera política configurada permite el tráfico, si lo hace lo deja pasar y ahí se terminó, pero si no es el caso pasará a la siguiente política y así sucesivamente hasta la última, la última siempre tiene que ser un ANY ANY ANY DENY, porque sino que gracia, no se bloquearía nada.
Antes había dos filosofías, denegar todo por defecto e ir aceptando tráfico o la de aceptar todo por defecto e ir denegando tráfico, por seguridad ahora en España solo es legal la primera, porque en caso de fallo, el tráfico está denegado.
Eso no significa que no realices políticas de bloqueo más precisas, por ejemplo, sabemos la lista de IPs de Emotet, se pueden añadir a una política de Lista Negra arriba para que según entre una petición o salga una petición hacia esos servidores maliciosos, se elimine, y mejorar el rendimiento del FW y hacer que consuma menos recursos, porque no tendrá que matchear política a política hasta el final, lo que ahorrará tiempo y recursos del FW.
Así a brote pronto voy a dejar esto así, si veo que os mola y queréis que os cuente más sobre esta tecnología, decídmelo y lo continuaré, esto quiero solo que sea como un pequeño artículo para que entendáis SUPERFICIALMENTE y de forma generalizada como funciona un FW y como se administra, buenas praxis... etc
