Una de DoS…

Hola de nuevo.

A continuación os dejo un par de enlaces sobre artículos publicados en la página de INCIBE sobre ataques DoS (Denial of Service).

En el primero de ellos se hace una definición del ataque en sí mismo; tipos; taxonomía por tipo de ataque y finalmente su clasificación dentro del modelo de referencia OSI.

En el segundo, se habla más concretamente del tipo de ataque centrado en a nivel de infraestructura, esto es el empleo de protocolos como TCP, UDP e ICMP.

Merece la pena dedicarles unos minutos ya que explica de una manera sencilla algo que continuamente oímos y que a veces no sabemos la raíz de cómo o con qué medios se produce.

A lo dicho, aquí os lo dejo para que les echéis un vistazo.

Clasificación de ataques DoS.

DoS en Capa de Infraestructura

Espero que os gusten.

Herramientas de Gestión, Parte I

Muchas veces nos ponemos a hablar de distintos temas y nos olvidamos de otros muchos más básicos que han de darse para que éstos puedan llevarse a cabo. Que no cunda el pánico, me explico…

Una de las labores principales que tienen los administradores de infraestructuras es garantizar el correcto funcionamiento de las mismas, ya que sobre ellas se sustenta la actividad de las organizaciones a las que pertenecen, ya sean organismos, instituciones o empresas privadas. Para que esto sea así, han de establecerse unas políticas y estrategias de tolerancia a fallos, seguridad, emergencia, etc. con las que poder hacer frente a los posibles incidentes que se puedan dar. Aquí podríamos establecer dos tipos de planteamientos; el preventivo, cara a la realización de tareas y ejercicios controlados, con los cuales poder evitar que estos sucesos ocurran, como pueden ser el apagado controlado de equipos, eliminación de enlaces redundantes, apagado de fuentes de alimentación, etc. Y por otro lado, el reactivo, esto es, la capacidad de respuesta ante un incidente que pueda comprometer la operativa de la red y que dependiendo de su categorización requerirá de unos tiempos de respuesta máximos para restablecer los servicios de los sectores afectados.

En cualquier caso, se requiere pues de un control y una gestión estricta de nuestro equipamiento, especialmente cuando se habla de infraestructuras de una envergadura considerable donde no sólo porque se puedan ver afectados un número importante de clientes finales sino también por el volumen de dispositivos de networking.

En este punto los administradores han de tener una serie de herramientas que permitan gestionar y monitorizar la red. Aquí debemos definir bien estos dos conceptos ya que, a veces, inducen a error. Cuando hablamos de herramientas de gestión, estamos hablando de software con el que podremos intervenir sobre nuestros equipos, realizando tareas como el cambio de parámetros, configuraciones, actualizaciones de software, representación gráfica de la topología de la red, etc. Por otro lado, tendríamos las herramientas de monitorización, con la que podemos conocer el estado funcional de nuestros equipos y componentes, así como volumen de tráfico en enlaces, porcentaje de utilización, etc. Además, en el caso de producirse algún comportamiento anómalo, poder  recibir, algún tipo de alerta como un correo electrónico o SMS.

 Los distintos fabricantes ofrecen entre sus productos dichas herramientas, previo pago claro está de una licencia que puede ir en función del tipo de funcionalidades disponibles, volumen de equipos o cualquier otro criterio que consideren oportuno. No obstante, las hay también de software libre, especialmente en lo que a monitorización se refiere.

Algunas de las herramientas de gestión que podemos encontrar podría ser Cisco Prime Infraestructure, la cual, ha sustituido a Cisco Prime LMS (Lan Management Solution). Cisco Prime Infraestructure ha sido diseñada para poder hacer frente no sólo a redes cableadas sino también a inalámbricas, pudiendo aglutinar las funcionalidades que daba el appliance WCS (Wireless Control System). Por ahora yo trabajo con ambas, y personalmente en lo que a redes cableadas se refiere me gusta más LMS que Infraestructure, justo lo contrario que para las redes inalámbricas.

Cualquiera de ellas tienen una gran cantidad de funcionalidades, no sólo puramente de gestión sino además de monitorización, troubleshooting, auditoría, reporting, etc. Alguna de ellas son:

                1.- Actualización de software en dispositivos.

                2.- Cambios en las configuraciones.

                3.-  Representaciones gráficas.

                4.- Elaboración de informes.

                5.- Gestión de alertas.

                6.- Gestión de logs.

                7.- Detección de discrepancias en red.

                8.- Monitorización.

Aquí os dejo algunas capturas que, muchas veces una imagen vale más que mil palabras.

Pantalla de login.

Página inicial. Allí ya podemos ver una gráfica con el resumen del hardware detectado, discrepacias en configuraciones, desviaciones de las mejores prácticas, etc.

Funcionalidad para ver la imagen del switch. En verde puertos en funcionamiento; en naranja, los deshabilitados; y en amarillo, los operativos pero que no tienen ningún equipo conectado.

Si pinchásemos sobre alguno de los puertos podríamos realizar algunas configuraciones. En nuestro caso el 1/1.

Si quisiésemos programar un reinicio de uno o varios switches podríamos ir a Configuration-NetConfig y allí, pincharemos sobre Create.

En función del elemento sobre el cual realizaremos la acción en cuestión, deberemos elegir  entre dispositivo, módulo o puerto. En nuestro caso puesto que vamos a reiniciar el equipo elegiremos, Device Based.

Elegimos el, o los equipos, y la tarea, en nuestro caso “Reload”.

Damos un nombre y si queremos programarla fecha y hora; y algunos parámetros adicionales.

 

 

 

Finalmente nos sale un resumen con los pasos a seguir y ya estaría lista la tarea.

Así cómo hemos visto se podrían llevar a cabo otras muchas tareas de distinta índole y explotar otra gran cantidad de  funcionalidades. Lo que se pretende es hacer una vista rápida de este tipo de herramientas y de lo que pueden llegar a hacer. Para la próxima daremos algunos ejemplos de Cisco Prime Infraestructure.

Distribuciones para seguridad y servicios de red

Que la seguridad es un elemento clave en cualquier entorno sea en infraestructuras de comunicaciones, informática o entornos industriales es algo que a esta altura del partido nadie se cuestiona.  Controlar el acceso a la red, los ficheros, gestionar los permisos y derechos de los usuarios, cifrado de comunicaciones, filtrado de contenidos, etc. etc. son algunas de tantas medidas que podremos adoptar para garantizar una seguridad global y proteger así nuestra información.

Como es costumbre no voy hablar de las configuraciones que nos ofrecen los Sistemas Operativos o aplicaciones sino que nos ceñiremos, como siempre, a las comunicaciones. Desde este punto de vista los firewalls e IDS/IPS juegan un papel clave. Deberemos empezar por tener muy claro dónde situarlos para proteger unos u otros segmentos de red en función de lo que allí tengamos. Mientras que los Cortafuegos permitirán o denegarán el tráfico dirigido equipos que prestan algún tipo de servicio; los IDS/IPS se encargarán de analizarlo y detectar posibles patrones de ataques o “movimientos” hostiles en nuestra red. Y si es posible, tomar alguna medida para bloquearlo.

Cada uno de nosotros tenemos una disciplina profesional definida, lo cual no quita que tengamos que saber de otras que circulan a nuestro alrededor. Todo lleva un aprendizaje previo, y con él un tiempo que puede no tengamos, al menos, para especializarnos todo que quisiéramos. Da igual si hablamos de tecnologías, comunicaciones, sistemas, aplicaciones, entornos,… todo lleva lo suyo. Por no hablar de las soluciones propietarias de fabricantes, que si Cisco saca tal o cual prestación, Juniper hace algo parecido con distinto nombre, etc. etc. vamos, la historia de nunca acabar.

Para facilitarnos las cosas, por suerte, existen algunos proyectos e iniciativas con los que podemos contar para que, con una menor inversión de tiempo y conocimientos, podamos acceder a ciertos sistemas, aplicaciones y funcionalidades. Tal es el caso de las distribuciones con un conjunto de herramientas dispuestas a cumplir con un fin concreto. Así como dentro del mundo de la seguridad y pentesting tenemos a “Kali” existen otras, las cuales están orientadas a la seguridad o servicios de red, que presento a continuación.

Firewalls

SmoothWall Firewall

M0n0wall

BrazilFW, Firewall and Router

IDS

SmoothSec

EasyIDS

Monitorización de redes

FAN, Fully Automated Nagios

Seguridad de redes

NST, Network Security Toolkit

Router

BSD Router Distribution

En el siguiente enlace os dejo un listado que podréis encontrar en Wikipedia donde se incluyen bastantes más, algunos incluso descontinuados. Pinchar aqui.

Almacenamiento

FreeNAS

Openfiler

Aparte de la facilidad de su despliegue y su uso gracias a sus interfaces gráficas, otra de las ventajas a destacar es su costo. Al estar basados en software libre, se hacen propicios en entornos donde no se cuente con recursos económicos para adquirir otro tipo de soluciones comerciales, o incluso sustituirlas según sean los casos. Pensemos, por ejemplo, en una PYME que pueda reutilizar un equipo reemplazado y que dotándolo con unas tarjetas de red adicionales pueda convertirse en un cortafuegos, router, web proxy, servidor VPN, o lo que sea. Lo que quiero decir es que no necesitamos invertir una cantidad de dinero más o menos considerable para garantizar la seguridad sino que además no tenemos que renunciar a ella en caso de no disponer de un capital para adquirir algún producto de los tantos que hay en el mercado.

En fin, bien por falta de tiempo o recursos económicos, no tenemos porqué perder unos servicios o funcionalidades en nuestras redes de datos. Tenemos a nuestra disposición un gran número de distribuciones, que sin tener un conocimiento exhaustivo de los sistemas sobre los cuales están basados, pueden cumplir con nuestras necesidades.

Otros modelos…

Para que nuestra red “funcione” y se comporte de la manera que necesitemos, no sólo tendremos que configurar e interconectar los equipos de la manera que más se ajuste a nuestros requerimientos, sino hacerlo siguiendo el mejor modelo. Cada organización, empresa o cualquiera que tenga una infraestructura de comunicaciones tendrá los suyos propios, con lo que establecer un patrón genérico puede a veces no ser lo más idóneo.

Por ejemplo, muchos de nosotros se nos ha enseñado la idea de que una red está compuesta por 3 capas, “Acceso”, “Distribución” y “Core”. Obviamente debe existir una jerarquía  y una segmentación de las funciones pero, no siempre puede darse esta estructura. Os dejo un par de imágenes que representan esta idea:

Como digo, todas las organizaciones pueden no necesitarlo, y es más, con los tiempos que corren los recursos económicos no son los suficientes como para invertir en tanto equipo. Por eso, puede darse el caso como el que os traigo.

Lo que vamos a  hacer, es unir tanto la capa de “Core” como la de “Distribución”, con switches de Capa 3 y definiendo interfaces virtuales. Os dejo en enlace donde podréis ver un artículo donde hablaba de ello, pincha aquí.

¿Por qué esto? Bueno puede haber distintos motivos. El primero de ellos es que directamente no sea necesario; otro que al eliminar una de las capas, eliminamos los equipos que están en ella, y por tanto es menos dinero a invertir. Otra es que los equipos de hoy en día traen consigo muchas funcionalidades (Protocolos, configuraciones, medidas de seguridad, etc.) y capacidades (velocidad de conmutación,  densidad de puertos, etc.) comunes a ambas capas y por tanto no hacen necesario segmentarlo de esta manera. Sin embargo no todos son ventajas, y deberemos por tanto ser cuidadosos a la hora de diseñar la red. Es decir, si suprimimos una capa, podremos penalizar la escalabilidad.  Como todo, antes de hacer nada deberemos pensar muy bien lo que hacemos y analizar todas las necesidades de deba cumplir, a corto y medio plazo, nuestra infraestructura y los requerimientos que debamos ponerle a nuestros equipos.

Así pues a continuación ilustro este concepto de “unión”.

Como podemos ver, se colapsan las dos capara de “Core” y “Distribución”. Es un entorno que ofrece redundancia entre los equipos de acceso situados en la parte inferior de la imagen y los servidores en la superior. Tras haber evaluado las características de los equipos, éstos soportan protocolos de alta disponibilidad como HSRP, VRRP, STP, etc; también disponemos de enlaces redundantes tanto desde los switches de acceso, sw-of-01, así como como entre switches de Core/Distribución que nos proporciona una tolerancia ante fallos. Contando de que éstos tengan puertos a 1 Gbps podremos agregar enlaces (Etherchannel) para vencer posibles cuellos de botella al conectar más switches de acceso; también podremos implementar “Listas de Control de Acceso” (ACLs); y como no, al ser equipos de L3 configurar algún protocolo de enrutamiento (OSPF, EIGRP) o enrutado manual (ip route XXX.XXX.XXX.XXX ….) para el envío de pquetes.

Lo que se trata de hacer ver es que podremos llevar a cabo otras topologías, al margen claro está, de que los modelos “genéricos” no sean la mejor opción para posibles implementaciones a las que tengamos que hacer frente. Eso deberemos conocer y tener en cuenta todas las funcionalidades que los equipos y tecnologías nos ofrecen, sus costes y alternativas de fabricantes.

 Nos vemos en la próxima!!!

Liberada Guía avanzada de nmap 6

El pasado día 13 de diciembre se liberó una guía sobre el uso de la archiconocida herramienta para el descubrimiento y análisis de equipos, servicios, S.O. etc. en una red para propósitos de auditoría o pentesting; NMAP. La misma no sólo abarca su funcionamiento sino además las técnicas más empleadas en su uso y sus  características más avanzadas como el motor de scripting NSE. Fruto de la colaboración del Centro Criptológico Nacional (CCN) y el Centro de Seguridad TIC de la comunidad Valenciana (CSIRT-CV) ve la luz un excelente documento que hay que dedicarle su tiempo para sacarle todo lo que nos ofrece en sus 112 hojas.

Para su descarga pincha aquí.

Protegiendo STP, Parte II

Seguimos con STP. En esta ocasión vamos a ver algunos comandos sobre STP que nos van permitir evitar posibles ataques a este protocolo y que vimos en la “Parte I”.La primera de ella es proteger el switch que va a ejercer como “Root Bridge”. Esto es, si le llegase una BPDU con indicando que existe otro switch con una prioridad menor (bien porque se conecta uno o porque se generan mediante un software como Yersinia) no la considere, lo descarte. Se aplica sobre la interfaz que lo une a otros switches. En nuestro ejemplo se aplicaría sobre la Fa 1/0 en el “SW-CORE-01”.

SW-CORE-01(config-if)# spanning-tree guard root 

Otra de las configuraciones a realizar es activar la opción “BPDU Guard”. Este parámetro configurado en los puertos de los switches de acceso provocará que el puerto se deshabilite al recibir una BPDU. A diferencia del anterior, este comando habría que ejecutarlo en los switches de acceso, sonde se conectan los equipos finales ya que en caso de añadir un switch legítimo podrían no detectarse los bucles en la red y por tanto STP no ser efectivo

SW-OFICINAS-01(config-if) # spanning-tree bpduguard enable 

Igualmente, podríamos conseguir que el switch no envíe BPDUs sobre puertos donde tengamos un equipo final, ya que estamos seguros de que no es necesario enviar información de STP. ¿Para qué mandar información que no es necesaria?

SW-OFICINAS-01(config-if) # spanning-tree bpdufilter enable 

STP nos ofrece otras muchas configuraciones también de utilidad. Quizás no tanto con la seguirdad pero só con la funcionalidad. Por ejemplo, podríamos ser capaces de que un switch sea el “Root Bridge” y otro sea un “Backup” de éste. En el nuestro esto sería:

SW-CORE-01(config) # spannig-tree vlan 10 root primary

SW-CORE-02(config) # spannig-tree vlan 10 root secondary

¿Qué quiere decir esto? Para VLAN 10, el switch “SW-CORE-01” el será el root bridge. Si éste cae, el “SW-CORE-02” será el “Root Bridge”. ¿Cómo se consigue esto? Ambos switches modificarán sus prioridades para que el “SW-CORE-01” sea el primario y el “SW-CORE-02” el “Backup” en un funcionamiento normal.

Existen más comandos que permiten modificar y optimizar los valores que STP tiene por defecto, pero no entraremos en ellos ya no es el objetivo de esta entrada. Por ahora lo dejamos así.

Un saludo, seguiremos informando…