Security Onion Parte 1
Imagino que todos habéis leído la noticia de la aparición de la nueva versión de Security Onion Distro 12.04 y voy a intentar explicar un poco de donde viene todo esto, como funciona, y a donde va.
Básicamente es una distro. Ubuntu con ciertos paquetes "in box" es decir, configurados entre sí para ofrecer al usuario una experiencia de monitorización nunca vista hasta la fecha ( lo siento, quería ponerme en la piel de un vende-humo !!).
Para configurar esta distro no es necesario mucho más de 5 minutos. Para configurar la integración de herramientas que nos ofrece, a pelo, sería cuestión de mucho más, muuuuucho mas. Pero como todo, es básico entender el funcionamiento de los componentes, su interrelación, mantenimiento, etc.
Entonces, entendemos que Security Onion es un Network Security Monitor, gracias a los componentes: Bro Ids,Motor de detección Snort o Suricata, Sguil, Squert, ELSA, Snorby, CapMe y toda una lista de herramientas que lo hacen perfecto para monitorizar en tiempo real nuestra actividad de red, multihilo, multiprotocolo (tcp,udp...) a nivel de aplicación (ftp,http...) y con capacidad para análisis forense, gracias a la posibilidad de almacenar/insertar ficheros de captura pcap.
Una de las cosas que tenemos que tener en cuenta antes de configurar el aplicativo, es el tamaño. El tamaño si que importa, y tener un sensor instalado entre una vlan de servidores y un entorno de clientes, en una red de 100mbps puede ser una tarea que requiera muuuuchos megas. Por ejemplo en ese caso:
100 Mb/s = 12,5 MB/s ** si no encuentras "al algoritmo de conversion" sal de esta web !!!!
1 hora= 45.000 MB
1 dia= 1080 GIGAS....1 TB al día.
No creo que haya actividad entre dos elementos al 100% en todo momento, es más, si tienes este "issue" es que no estas administrando algo bien xD, pero para hacerse una idea de la dimensión del proyecto nos sirve.
Otra cuestión es la ubicación del sniffer. Como hacemos para escuchar el tráfico de las dos redes que queremos monitorizar? Los que habéis jugado con herramientas de arp spoofing sabeis el problema de rendimiento que supone poner una máquina en modo promiscuo realizando el envenenamiento. Si usas un portátil, con su tarjetica de red cutre, y te pones a esnifar una red de ...10 ordenadores... verás como en 5 minutos te empiezan a llamar con caídas de servicio de todo tipo, lógico. Los que no, ya lo sabéis.
Para jugar en casa, en un laboratorio podemos usar un HUB conectado entre los segmentos de red, y en una de sus bocas nuestro Security Onion en modo promiscuo. El HUB me hará de port mirroring por sus características de funcionamiento,pero las mismas características nos limitarán el FULL DUPLEX, es decir, que dividirá la velocidad entre los puertos usados... En entornos de producción sería como cortar el canuto por la mitad.
Para ubicar nuestro Security Onion en un entorno de producción sería recomendable usar un switch gestionable con capacidad de realizar SPAN (swith port analysis), es decir, lo mismo que hacíamos con el HUB de replicar el contenido de una "boca" a otra, pero sin perder rendimiento y fiabilidad.
Por lo que se de otros compañeros, en entornos productivos "serios" se usan unos aparatejos llamados TAP que simplemente hacen un "hombre en el medio" físico sin perdida de rendimiento y fiabilidad (paquetes perdidos...).
El señor Alfon tiene un buen artículo sobre como realizar la tarea de adquisición.
Con esto acabo la introducción a este NSM y unos pocos conceptos a tener en cuenta.
En próximas entregas hablaremos de su instalación, puesta en marcha y uso.
Gracias por leerme.
Por otro lado aprovecho la ocasión para comentar que he habilitado una nueva página dentro del blog, denominada Community Protección Project para recopilar artículos en castellano sobre medidas de seguridad para nuestros sistemas. Tenemos pues un recopilatorio para realizar nuestros test de intrusión, y por otro lado para "evitar" estos test de intrusión. Quien ganará? espero que todos xD y no solo los fabricantes de soluciones :-).
Básicamente es una distro. Ubuntu con ciertos paquetes "in box" es decir, configurados entre sí para ofrecer al usuario una experiencia de monitorización nunca vista hasta la fecha ( lo siento, quería ponerme en la piel de un vende-humo !!).
Para configurar esta distro no es necesario mucho más de 5 minutos. Para configurar la integración de herramientas que nos ofrece, a pelo, sería cuestión de mucho más, muuuuucho mas. Pero como todo, es básico entender el funcionamiento de los componentes, su interrelación, mantenimiento, etc.
Entonces, entendemos que Security Onion es un Network Security Monitor, gracias a los componentes: Bro Ids,Motor de detección Snort o Suricata, Sguil, Squert, ELSA, Snorby, CapMe y toda una lista de herramientas que lo hacen perfecto para monitorizar en tiempo real nuestra actividad de red, multihilo, multiprotocolo (tcp,udp...) a nivel de aplicación (ftp,http...) y con capacidad para análisis forense, gracias a la posibilidad de almacenar/insertar ficheros de captura pcap.
Una de las cosas que tenemos que tener en cuenta antes de configurar el aplicativo, es el tamaño. El tamaño si que importa, y tener un sensor instalado entre una vlan de servidores y un entorno de clientes, en una red de 100mbps puede ser una tarea que requiera muuuuchos megas. Por ejemplo en ese caso:
100 Mb/s = 12,5 MB/s ** si no encuentras "al algoritmo de conversion" sal de esta web !!!!
1 hora= 45.000 MB
1 dia= 1080 GIGAS....1 TB al día.
No creo que haya actividad entre dos elementos al 100% en todo momento, es más, si tienes este "issue" es que no estas administrando algo bien xD, pero para hacerse una idea de la dimensión del proyecto nos sirve.
Otra cuestión es la ubicación del sniffer. Como hacemos para escuchar el tráfico de las dos redes que queremos monitorizar? Los que habéis jugado con herramientas de arp spoofing sabeis el problema de rendimiento que supone poner una máquina en modo promiscuo realizando el envenenamiento. Si usas un portátil, con su tarjetica de red cutre, y te pones a esnifar una red de ...10 ordenadores... verás como en 5 minutos te empiezan a llamar con caídas de servicio de todo tipo, lógico. Los que no, ya lo sabéis.
Para jugar en casa, en un laboratorio podemos usar un HUB conectado entre los segmentos de red, y en una de sus bocas nuestro Security Onion en modo promiscuo. El HUB me hará de port mirroring por sus características de funcionamiento,pero las mismas características nos limitarán el FULL DUPLEX, es decir, que dividirá la velocidad entre los puertos usados... En entornos de producción sería como cortar el canuto por la mitad.
Para ubicar nuestro Security Onion en un entorno de producción sería recomendable usar un switch gestionable con capacidad de realizar SPAN (swith port analysis), es decir, lo mismo que hacíamos con el HUB de replicar el contenido de una "boca" a otra, pero sin perder rendimiento y fiabilidad.
Por lo que se de otros compañeros, en entornos productivos "serios" se usan unos aparatejos llamados TAP que simplemente hacen un "hombre en el medio" físico sin perdida de rendimiento y fiabilidad (paquetes perdidos...).
El señor Alfon tiene un buen artículo sobre como realizar la tarea de adquisición.
Con esto acabo la introducción a este NSM y unos pocos conceptos a tener en cuenta.
En próximas entregas hablaremos de su instalación, puesta en marcha y uso.
Gracias por leerme.
Por otro lado aprovecho la ocasión para comentar que he habilitado una nueva página dentro del blog, denominada Community Protección Project para recopilar artículos en castellano sobre medidas de seguridad para nuestros sistemas. Tenemos pues un recopilatorio para realizar nuestros test de intrusión, y por otro lado para "evitar" estos test de intrusión. Quien ganará? espero que todos xD y no solo los fabricantes de soluciones :-).
