{"id":37437,"date":"2019-10-31T22:17:38","date_gmt":"2019-10-31T19:17:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\/"},"modified":"2019-10-31T22:17:38","modified_gmt":"2019-10-31T19:17:38","slug":"flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Cuando se habla de la monitorizaci\u00f3n de la seguridad de una red corporativa o gubernamental, muchos asocian esto con el control de las filtraciones de informaci\u00f3n y la implementaci\u00f3n de soluciones DLP. Pero si intentamos precisar la pregunta y preguntar c\u00f3mo detectan ataques en la red interna, la respuesta suele ser una menci\u00f3n a los sistemas de detecci\u00f3n de intrusos (IDS). Lo que sol\u00eda ser la \u00fanica opci\u00f3n hace 10 o 20 a\u00f1os, hoy se est\u00e1 convirtiendo en un anacronismo. Existe una opci\u00f3n m\u00e1s eficaz, que en ciertos casos es incluso la \u00fanica posible para la monitorizaci\u00f3n de la red interna: utilizar protocolos de flujo, que originalmente estaban destinados a la b\u00fasqueda de problemas de red (troubleshooting), pero que con el tiempo se han transformado en una herramienta de seguridad muy interesante. En este art\u00edculo hablaremos sobre los distintos tipos de protocolos de flujo, cu\u00e1les son los m\u00e1s adecuados para detectar ataques de red, d\u00f3nde es mejor implementar la monitorizaci\u00f3n de flujo, en qu\u00e9 aspectos fijarse al desplegar este tipo de esquema, e incluso c\u00f3mo se puede<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>No me detendr\u00e9 en la cuesti\u00f3n de \u201c\u00bfPor qu\u00e9 es necesaria la monitorizaci\u00f3n de la seguridad de la infraestructura interna?\u201d La respuesta parece obvia. Pero si a\u00fan as\u00ed quisieran asegurarse de que hoy en d\u00eda esto es indispensable, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">mire<\/a><\/noindex> un breve video que explica c\u00f3mo se puede acceder a una red corporativa protegida por un cortafuegos de 17 maneras diferentes. Por lo tanto, consideremos que entendemos que la monitorizaci\u00f3n interna es necesaria y solo queda aclarar c\u00f3mo se puede organizar.<\/p>\n<p>Identificar\u00eda tres fuentes clave de datos para la monitorizaci\u00f3n de la infraestructura a nivel de red:<\/p>\n<ul>\n<li>tr\u00e1fico \u201ccrudo\u201d que capturamos y enviamos a sistemas de an\u00e1lisis para su evaluaci\u00f3n,<\/li>\n<li>eventos procedentes de dispositivos de red por los que transita el tr\u00e1fico,<\/li>\n<li>informaci\u00f3n sobre el tr\u00e1fico obtenida a trav\u00e9s de uno de los protocolos de flujo.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa captura de tr\u00e1fico bruto es la opci\u00f3n m\u00e1s popular entre los especialistas en seguridad, ya que hist\u00f3ricamente fue la primera en aparecer. Los sistemas de detecci\u00f3n de intrusiones (la primera de ellas fue NetRanger de Wheel Group, adquirida por Cisco en 1998) se encargan precisamente de capturar paquetes (y m\u00e1s tarde sesiones) en los que se buscan ciertas firmas (\"reglas decisivas\" en la terminolog\u00eda de la FSTEK) que indican ataques. Por supuesto, el an\u00e1lisis de tr\u00e1fico bruto se puede realizar no solo con IDS, sino tambi\u00e9n con otras herramientas (como Wireshark, tcpdump o la funcionalidad NBAR2 en Cisco IOS), pero suelen carecer de la base de conocimientos que distingue a una herramienta de seguridad de un simple recurso de TI.<\/p>\n<p>As\u00ed que, sistemas de detecci\u00f3n de intrusiones. El m\u00e9todo m\u00e1s antiguo y popular para detectar ataques de red, que se desempe\u00f1a razonablemente bien en el per\u00edmetro (sin importar cu\u00e1l \u2014 corporativo, centro de datos, segmento, etc.), pero que flaquea en redes modernas conmutadas y definidas por software. En el caso de una red construida con conmutadores est\u00e1ndar, la infraestructura de sensores de detecci\u00f3n de ataques se vuelve demasiado grande: tendr\u00e1s que instalar un sensor en cada conexi\u00f3n con un nodo cuyas amenazas deseas monitorear. Cualquier fabricante, por supuesto, estar\u00e1 encantado de venderte cientos y miles de sensores, pero creo que tu presupuesto no soportar\u00e1 tales gastos. Puedo decir que incluso en Cisco (donde desarrollamos NGIPS) no pudimos lograrlo, aunque, aparentemente, el precio no deber\u00eda ser un obst\u00e1culo \u2014 es nuestra propia soluci\u00f3n. Adem\u00e1s, surge la pregunta de c\u00f3mo conectar el sensor en tal caso. \u00bfEn la interrupci\u00f3n? \u00bfY si el propio sensor falla? \u00bfExigir un m\u00f3dulo bypass en el sensor? \u00bfUsar divisores (tap)? Todo esto encarece la soluci\u00f3n y la hace inalcanzable para empresas de cualquier tama\u00f1o.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe puede intentar \"colocar\" un sensor en un puerto SPAN\/RSPAN\/ERSPAN y dirigir el tr\u00e1fico desde los puertos necesarios del conmutador hacia \u00e9l. Esta opci\u00f3n alivia en parte el problema planteado en el p\u00e1rrafo anterior, pero plantea otro: el puerto SPAN no puede aceptar todo el tr\u00e1fico que se le env\u00ede, ya que no tendr\u00e1 la capacidad suficiente. Habr\u00e1 que sacrificar algo. O dejar algunas m\u00e1quinas sin monitoreo (en cuyo caso ser\u00e1 necesario priorizarlas previamente), o dirigir no todo el tr\u00e1fico desde un nodo, sino solo cierto tipo. En cualquier caso, podemos perder algunos ataques. Adem\u00e1s, el puerto SPAN puede estar ocupado para otros fines. Al final, tendremos que reconsiderar la topolog\u00eda de red existente y realizar, posiblemente, ajustes en ella para abarcar al m\u00e1ximo su red con el n\u00famero de sensores que tiene (y coordinarlo con IT).<\/p>\n<p>\u00bfY si su red utiliza rutas asim\u00e9tricas? \u00bfY si tiene implementado o est\u00e1 planeando implementar SDN? \u00bfY si necesita monitorear m\u00e1quinas virtuales o contenedores, cuyo tr\u00e1fico no llega al conmutador f\u00edsico? Estas preguntas no son del agrado de los fabricantes de IDS tradicionales, porque no saben c\u00f3mo responderlas. Es posible que intenten persuadirlo de que todas estas tecnolog\u00edas de moda son una exageraci\u00f3n y que no las necesita. Tal vez hablen de la necesidad de empezar poco a poco. O quiz\u00e1s dir\u00e1n que debe instalar una potente m\u00e1quina en el centro de la red y redirigir todo el tr\u00e1fico hacia ella mediante balanceadores. Cualquiera que sea la opci\u00f3n que le ofrezcan, necesita entender claramente cu\u00e1n adecuada es para usted. Y solo despu\u00e9s de eso, tomar una decisi\u00f3n sobre el enfoque para el monitoreo de la infraestructura de seguridad de red. Volviendo a la captura de paquetes, debo decir que este m\u00e9todo sigue siendo muy popular e importante, pero su prop\u00f3sito principal es el control de fronteras: las fronteras entre su organizaci\u00f3n y la Internet, las fronteras entre el centro de datos y la red restante, las fronteras entre los sistemas de control industrial y el segmento corporativo. En estos lugares, los IDS\/IPS cl\u00e1sicos a\u00fan tienen raz\u00f3n de ser y cumplen bien con las tareas asignadas.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPasemos a la segunda opci\u00f3n. El an\u00e1lisis de eventos provenientes de dispositivos de red tambi\u00e9n puede ser utilizado para detectar ataques, aunque no como un mecanismo principal, ya que permite detectar solo un peque\u00f1o grupo de intrusiones. Adem\u00e1s, tiene cierta reactividad: primero debe ocurrir un ataque, luego debe ser registrado por el dispositivo de red, el cual de alguna manera se\u00f1alar\u00e1 el problema de ciberseguridad. Existen varios m\u00e9todos para ello. Puede ser syslog, RMON o SNMP. Los \u00faltimos dos protocolos para monitoreo de red en el contexto de ciberseguridad se utilizan solo si necesitamos detectar un ataque DoS contra el propio equipo de red, ya que con RMON y SNMP se puede, por ejemplo, monitorear la carga del CPU del dispositivo o sus interfaces. Este es uno de los m\u00e9todos m\u00e1s \u201cecon\u00f3micos\u201d (syslog o SNMP est\u00e1n disponibles para todos), pero tambi\u00e9n el menos efectivo para el monitoreo de ciberseguridad de la infraestructura interna: muchos ataques simplemente est\u00e1n ocultos para \u00e9l. Desde luego, no se deben menospreciar, y el mismo an\u00e1lisis de syslog te ayuda a identificar a tiempo los cambios en la configuraci\u00f3n del propio dispositivo, as\u00ed como su compromiso, pero no es muy adecuado para detectar ataques en toda la red.<\/p>\n<p>La tercera opci\u00f3n es el an\u00e1lisis de la informaci\u00f3n sobre el tr\u00e1fico que pasa a trav\u00e9s de un dispositivo que soporta uno de varios protocolos de flujo. En este caso, independientemente del protocolo, la infraestructura de trabajo con flujos consta obligatoriamente de tres componentes:<\/p>\n<ul>\n<li>Generaci\u00f3n o exportaci\u00f3n de flujo. Este papel generalmente recae en el enrutador, conmutador u otro dispositivo de red que, al permitir que el tr\u00e1fico de red pase a trav\u00e9s de \u00e9l, permite extraer par\u00e1metros clave que luego se env\u00edan al m\u00f3dulo de recolecci\u00f3n. Por ejemplo, en Cisco, el protocolo Netflow se soporta no solo en enrutadores y conmutadores, incluyendo virtuales e industriales, sino tambi\u00e9n en controladores inal\u00e1mbricos, cortafuegos e incluso servidores.<\/li>\n<li>Recolecci\u00f3n de flujo. Dado que en una red moderna generalmente hay m\u00e1s de un dispositivo de red, surge la tarea de recopilar y consolidar los flujos, que se resuelve mediante lo que se llama recolectores, que procesan los flujos recibidos y luego los env\u00edan para su an\u00e1lisis.<\/li>\n<li>An\u00e1lisis de flujo. El analizador asume la tarea intelectual principal y, aplicando diferentes algoritmos a los flujos, llega a diversas conclusiones. Por ejemplo, en el contexto de funciones de TI, dicho analizador puede detectar cuellos de botella en la red o analizar el perfil de carga del tr\u00e1fico para optimizar la red. Para la seguridad de la informaci\u00f3n, este analizador puede descubrir filtraciones de datos, la propagaci\u00f3n de c\u00f3digo malicioso o ataques DoS. <\/li>\n<\/ul>\n<p>No hay que pensar que tal arquitectura de tres capas es demasiado compleja; todas las dem\u00e1s opciones (excepto, quiz\u00e1s, los sistemas de monitorizaci\u00f3n de red que funcionan con SNMP y RMON) tambi\u00e9n operan de acuerdo con ella. Contamos con un generador de datos para el an\u00e1lisis, que es un dispositivo de red o un sensor independiente. Tenemos un sistema para recopilar se\u00f1ales de alarma y un sistema para gestionar toda la infraestructura de monitorizaci\u00f3n. Estos dos \u00faltimos componentes pueden integrarse en un solo nodo, pero en redes medianas o grandes, normalmente se distribuyen en al menos dos dispositivos para asegurar escalabilidad y fiabilidad.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA diferencia del an\u00e1lisis de paquetes, que se basa en el estudio de los encabezados y el cuerpo de los datos de cada paquete y las sesiones que estos componen, el an\u00e1lisis de flujos se basa en la recopilaci\u00f3n de metadatos sobre el tr\u00e1fico de red. \u00bfCu\u00e1ndo, cu\u00e1nto, de d\u00f3nde y hacia d\u00f3nde, c\u00f3mo...? Estas son las preguntas que responde el an\u00e1lisis de la telemetr\u00eda de red mediante diversos protocolos de flujo. Inicialmente, se utilizaban para analizar estad\u00edsticas y buscar problemas de TI en la red, pero luego, a medida que los mecanismos anal\u00edticos se desarrollaron, se volvieron aplicables a la misma telemetr\u00eda para fines de seguridad. Cabe se\u00f1alar una vez m\u00e1s que el an\u00e1lisis de flujos no reemplaza ni anula la captura de paquetes. Cada uno de estos m\u00e9todos tiene su propio \u00e1mbito de aplicaci\u00f3n. Sin embargo, en el contexto de este art\u00edculo, el an\u00e1lisis de flujos es el m\u00e1s adecuado para monitorear la infraestructura interna. Ustedes tienen dispositivos de red (y no importa si operan bajo una paradigma definida por software o seg\u00fan reglas est\u00e1ticas) que no pueden ser eludidos por un ataque. Un sensor IDS cl\u00e1sico puede ser eludido, pero un dispositivo de red que soporte el protocolo de flujo no puede. Esta es la ventaja de este m\u00e9todo. <\/p>\n<p>Por otro lado, si necesita pruebas para las fuerzas del orden o su propio grupo de investigaci\u00f3n de incidentes, no puede prescindir de la captura de paquetes: la telemetr\u00eda de red no es una copia del tr\u00e1fico que se puede utilizar en la recopilaci\u00f3n de pruebas; es necesaria para la detecci\u00f3n operativa y la toma de decisiones en el \u00e1mbito de la seguridad de la informaci\u00f3n. Por otro lado, al utilizar el an\u00e1lisis de telemetr\u00eda, puede \"escribir\" no todo el tr\u00e1fico de red (si es necesario, Cisco y los centros de datos se encargan de ello :-), sino solo el que est\u00e1 involucrado en el ataque. Las herramientas de an\u00e1lisis de telemetr\u00eda complementan adecuadamente los mecanismos tradicionales de captura de paquetes, dando la orden para la captura y almacenamiento selectivo. De lo contrario, tendr\u00e1 que contar con una infraestructura de almacenamiento colosal.<\/p>\n<p>Imaginemos una red que opera a 250 Mbit\/s. Si desea almacenar todo ese volumen, necesitar\u00e1 un almacenamiento de 31 MB para un segundo de transmisi\u00f3n de tr\u00e1fico, 1,8 GB para un minuto, 108 GB para una hora y 2,6 TB para un d\u00eda. Para almacenar datos diarios de una red con un ancho de banda de 10 Gbit\/s, necesitar\u00e1 un almacenamiento de 108 TB. Y algunos reguladores exigen almacenar datos de seguridad durante a\u00f1os... La grabaci\u00f3n \"a demanda\", que el an\u00e1lisis de flujos le ayuda a implementar, reduce estos valores en \u00f3rdenes de magnitud. Por cierto, si hablamos de la relaci\u00f3n entre el volumen de datos grabados de la telemetr\u00eda de red y la captura completa de datos, es de aproximadamente 1 a 500. Para los valores mencionados anteriormente, el almacenamiento completo de la decodificaci\u00f3n de todo el tr\u00e1fico diario ser\u00eda de 5 y 216 GB, respectivamente (incluso se puede grabar en una memoria USB com\u00fan).<\/p>\n<p>Si bien para los medios de an\u00e1lisis de datos de red en crudo el m\u00e9todo de captura apenas difiere de un proveedor a otro, en el caso del an\u00e1lisis de flujos la situaci\u00f3n es diferente. Existen varias versiones de protocolos de flujo, sobre cuyas diferencias es necesario conocer, especialmente en el contexto de la seguridad. El protocolo m\u00e1s popular es Netflow, desarrollado por Cisco. Hay varias versiones de este protocolo, que var\u00edan en sus capacidades y en la cantidad de informaci\u00f3n sobre el tr\u00e1fico que registran. La versi\u00f3n actual es la novena (Netflow v9), sobre la cual se desarroll\u00f3 el est\u00e1ndar industrial Netflow v10, tambi\u00e9n conocido como IPFIX. Hoy en d\u00eda, la mayor\u00eda de los proveedores de redes soportan precisamente Netflow o IPFIX en su equipamiento. Sin embargo, hay varias otras versiones de protocolos de flujo: sFlow, jFlow, cFlow, rFlow, NetStream, etc., de las cuales la m\u00e1s popular es sFlow. Este es el que m\u00e1s a menudo es soportado por los fabricantes nacionales de equipos de red debido a su simplicidad de implementaci\u00f3n. \u00bfCu\u00e1les son las diferencias clave entre Netflow, que se ha convertido en un est\u00e1ndar de facto, y sFlow? Yo destacar\u00eda varias. Primero, Netflow tiene campos personalizables por el usuario, a diferencia de los campos fijos en sFlow. Y segundo, y esto es lo m\u00e1s importante en nuestro caso, sFlow recopila la llamada telemetr\u00eda muestreada; a diferencia de la telemetr\u00eda no muestreada de Netflow e IPFIX. \u00bfEn qu\u00e9 difieren entre s\u00ed?<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImagina que has decidido familiarizarte con el libro \u201c<noindex><a rel=\"nofollow\" href=\"http:\/\/www.ciscopress.com\/store\/security-operations-center-building-operating-and-maintaining-9780134052014\">Security Operations Center: Building, Operating, and Maintaining your SOC<\/a><\/noindex>\u201d de mis colegas \u2014 Gary McIntyre, Joseph Muniz y Nadeem AlFardan (en el enlace puedes descargar una parte del libro). Tienes tres opciones para alcanzar el objetivo: leer el libro completo, hojearlo, deteni\u00e9ndote en cada d\u00e9cima o vig\u00e9sima p\u00e1gina, o intentar encontrar un resumen de los conceptos clave en alg\u00fan blog o servicio tipo SmartReading. As\u00ed que la telemetr\u00eda no muestreada es como leer cada \u201cp\u00e1gina\u201d del tr\u00e1fico de red, es decir, analizar los metadatos de cada paquete. La telemetr\u00eda muestreada es el estudio selectivo del tr\u00e1fico con la esperanza de que en las muestras elegidas se encuentre lo que necesitas. Dependiendo de la velocidad del canal, la telemetr\u00eda muestreada devolver\u00e1 para an\u00e1lisis cada 64, 200, 500, 1000, 2000 o incluso cada 10000 paquetes.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn el contexto de la monitorizaci\u00f3n de la ciberseguridad, esto significa que la telemetr\u00eda muestreada es adecuada para detectar ataques DDoS, escaneos y propagaci\u00f3n de malware, pero puede pasar por alto ataques at\u00f3micos o multi-paquete que no se incluyan en la muestra enviada para an\u00e1lisis. La telemetr\u00eda no muestreada no tiene estas limitaciones, lo que ampl\u00eda significativamente el espectro de ataques detectables. Aqu\u00ed hay una peque\u00f1a lista de eventos que se pueden detectar mediante herramientas de an\u00e1lisis de telemetr\u00eda de red.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor supuesto, alg\u00fan analizador de Netflow de c\u00f3digo abierto no le permitir\u00e1 esto, ya que su principal tarea es recopilar la telemetr\u00eda y realizar un an\u00e1lisis b\u00e1sico desde el punto de vista de TI. Para identificar amenazas de ciberseguridad basadas en flujos, es necesario equipar al analizador con diversos motores y algoritmos que detecten problemas de ciberseguridad bas\u00e1ndose en campos est\u00e1ndar o personalizados de Netflow, enriqueciendo los datos est\u00e1ndar con informaci\u00f3n externa de varias fuentes de Threat Intelligence, etc.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor lo tanto, si tiene una opci\u00f3n, elija Netflow o IPFIX. Pero incluso si su equipo solo funciona con sFlow, como ocurre con algunos fabricantes nacionales, a\u00fan puede beneficiarse de ello en el contexto de la seguridad. <\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn el verano de 2019, realic\u00e9 un an\u00e1lisis de las capacidades disponibles de los fabricantes rusos de hardware de red, y todos ellos, excepto NSG, Pol\u00edgono y Kraftway, afirmaron soportar sFlow (al menos, Zelax, Natex, Eltex, QTech, Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa siguiente pregunta que se plantear\u00e1 es: \u00bfd\u00f3nde implementar el soporte para flow con fines de seguridad? En realidad, la pregunta no est\u00e1 formulada del todo correctamente. En el equipo moderno, el soporte para protocolos flow est\u00e1 casi siempre presente. Por lo tanto, reformular\u00eda la pregunta de otra manera: \u00bfd\u00f3nde es m\u00e1s efectivo recoger telemetr\u00eda desde el punto de vista de la seguridad? La respuesta ser\u00e1 bastante obvia: a nivel de acceso, donde ver\u00e1 el 100% del tr\u00e1fico, donde tendr\u00e1 informaci\u00f3n detallada sobre los hosts (MAC, VLAN, ID de interfaz), donde podr\u00e1 rastrear incluso el tr\u00e1fico P2P entre hosts, lo que es cr\u00edtico para detectar escaneos y la propagaci\u00f3n de c\u00f3digo malicioso. A nivel de n\u00facleo, puede que no vea parte del tr\u00e1fico, y a nivel de per\u00edmetro ver\u00e1, a lo sumo, una cuarta parte de todo su tr\u00e1fico de red. Pero si, por alguna raz\u00f3n, hay dispositivos ajenos en su red que permiten a los atacantes \u201centrar y salir\u201d, el an\u00e1lisis de la telemetr\u00eda desde all\u00ed no le servir\u00e1 de nada. Por eso, para una cobertura m\u00e1xima, se recomienda habilitar la recolecci\u00f3n de telemetr\u00eda precisamente a nivel de acceso. Cabe se\u00f1alar que incluso si hablamos de virtualizaci\u00f3n o contenedores, en los conmutadores virtuales modernos tambi\u00e9n suele haber soporte para flow, lo que permite controlar el tr\u00e1fico all\u00ed.<\/p>\n<p>Pero ya que he mencionado el tema, es necesario responder a la pregunta: \u00bfqu\u00e9 pasa si, de hecho, el hardware, f\u00edsico o virtual, no soporta protocolos flow? \u00bfO su activaci\u00f3n est\u00e1 prohibida (por ejemplo, en segmentos industriales para garantizar la fiabilidad)? \u00bfO su activaci\u00f3n provoca una alta carga en el procesador central (lo cual sucede en equipos obsoletos)? Para resolver este problema, existen sensores virtuales especializados (flow sensor), que en esencia son simples divisores que permiten pasar tr\u00e1fico a trav\u00e9s de ellos y lo retransmiten en forma de flow a un m\u00f3dulo de recolecci\u00f3n. Sin embargo, en este caso, nos enfrentamos a todo un c\u00famulo de problemas que mencionamos anteriormente en relaci\u00f3n con los medios de captura de paquetes. Es decir, hay que entender no solo las ventajas de la tecnolog\u00eda de an\u00e1lisis de flujos, sino tambi\u00e9n sus limitaciones.<\/p>\n<p>Otro aspecto importante a tener en cuenta al hablar sobre las herramientas de an\u00e1lisis de flujos. Si para las herramientas convencionales de generaci\u00f3n de eventos de seguridad aplicamos la m\u00e9trica EPS (eventos por segundo), para el an\u00e1lisis de telemetr\u00eda este indicador no es aplicable; se reemplaza por FPS (flujos por segundo). Al igual que con EPS, no se puede calcular de antemano, pero se puede estimar el n\u00famero aproximado de flujos que genera un dispositivo seg\u00fan su tarea. En Internet, puedes encontrar tablas con valores aproximados para diferentes tipos de dispositivos corporativos que te permitir\u00e1n calcular qu\u00e9 licencias necesitas para las herramientas de an\u00e1lisis y cu\u00e1l ser\u00e1 su arquitectura. La cuesti\u00f3n es que el sensor IDS tiene un ancho de banda limitado que puede 'soportar', y el colector de flujos tambi\u00e9n tiene sus restricciones que hay que entender. Por lo tanto, en redes grandes y distribuidas geogr\u00e1ficamente, suele haber m\u00faltiples colectores. Cuando describ\u00ed, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">c\u00f3mo se monitorea la red dentro de Cisco<\/a><\/noindex>, ya mencion\u00e9 el n\u00famero de nuestros colectores: son 21. Y eso para una red dispersa por cinco continentes y que cuenta con alrededor de medio mill\u00f3n de dispositivos activos).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo sistema de monitoreo de Netflow, utilizamos nuestra propia soluci\u00f3n <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, que est\u00e1 especialmente orientado a resolver problemas de seguridad. Tiene muchos motores integrados para detectar actividades an\u00f3malas, sospechosas y claramente malignas, lo que permite identificar una amplia gama de amenazas diferentes, desde miner\u00eda de criptomonedas hasta filtraciones de informaci\u00f3n, desde la distribuci\u00f3n de malware hasta el fraude. Al igual que la mayor\u00eda de los analizadores de flujos, Stealthwatch se basa en un esquema de tres niveles (generador - colector - analizador), pero se complementa con una serie de caracter\u00edsticas interesantes que son importantes en el contexto del material tratado. Primero, se integra con soluciones de captura de paquetes (por ejemplo, Cisco Security Packet Analyzer), lo que permite grabar sesiones de red seleccionadas para una posterior investigaci\u00f3n y an\u00e1lisis en profundidad. En segundo lugar, especialmente para ampliar las capacidades de seguridad, hemos desarrollado un protocolo especial, nvzFlow, que permite<\/p>\n<p>Es evidente que, al hablar sobre sistemas de an\u00e1lisis de Netflow desde la perspectiva de la seguridad, el mercado no se limita a una \u00fanica soluci\u00f3n de Cisco. Puedes utilizar tanto soluciones comerciales como gratuitas o de pago condicional. Es un tanto extra\u00f1o que en el blog de Cisco d\u00e9 ejemplos de soluciones de competidores, as\u00ed que comentar\u00e9 un par de palabras sobre c\u00f3mo puede analizarse la telemetr\u00eda de red con dos herramientas populares, que tienen nombres similares pero son, no obstante, diferentes: SiLK y ELK.<\/p>\n<p>SiLK es un conjunto de herramientas (el Sistema para el Conocimiento a Nivel de Internet) para el an\u00e1lisis de tr\u00e1fico, desarrollado por el CERT\/CC estadounidense. En el contexto del art\u00edculo de hoy, soporta Netflow (versiones 5 y 9, las m\u00e1s populares), IPFIX y sFlow, y mediante diversas utilidades (rwfilter, rwcount, rwflowpack, entre otras) lleva a cabo diversas operaciones sobre la telemetr\u00eda de red para detectar signos de acciones no autorizadas. Sin embargo, hay un par de puntos importantes a se\u00f1alar. SiLK es una herramienta de l\u00ednea de comandos, y realizar un an\u00e1lisis operativo siempre requiere introducir comandos como (detecci\u00f3n de paquetes ICMP de m\u00e1s de 200 bytes):<\/p>\n<p><code>rwfilter --flowtypes=all\/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15<\/code><\/p>\n<p>no es muy conveniente. Puede utilizar la interfaz gr\u00e1fica iSiLK, pero esta no facilitar\u00e1 mucho su vida, ya que solo cumple con la funci\u00f3n de visualizaci\u00f3n y no sustituye al analista. Y este es el segundo punto. A diferencia de las soluciones comerciales, que ya tienen una s\u00f3lida base anal\u00edtica, algoritmos de detecci\u00f3n de anomal\u00edas, flujos de trabajo, etc., en el caso de SiLK, usted deber\u00e1 realizar todo eso por su cuenta, lo que requerir\u00e1 de competencias diferentes a las de usar un conjunto de herramientas ya listo para funcionar. Esto no es ni bueno ni malo, es una caracter\u00edstica de pr\u00e1cticamente cualquier herramienta gratuita, que asume que usted sabe qu\u00e9 hacer, y solo le ayuda en eso (los conjuntos de herramientas comerciales son menos dependientes de las competencias de sus usuarios, aunque tambi\u00e9n suponen que los analistas entienden al menos las bases de las investigaciones y el monitoreo de redes). Pero volvamos a SiLK. El ciclo de trabajo de un analista con esta herramienta es el siguiente:<\/p>\n<ul>\n<li>Formulaci\u00f3n de una hip\u00f3tesis. Debemos entender qu\u00e9 buscaremos dentro de la telemetr\u00eda de red, conocer los atributos \u00fanicos que utilizaremos para identificar ciertas anomal\u00edas o amenazas.<\/li>\n<li>Construcci\u00f3n de un modelo. Una vez formulada la hip\u00f3tesis, la programamos con Python, shell u otras herramientas que no est\u00e1n incluidas en SiLK.<\/li>\n<li>Pruebas. Llega el momento de verificar la validez de nuestra hip\u00f3tesis, que se confirma o se refuta utilizando utilidades SiLK que comienzan con 'rw', 'set', 'bag'.<\/li>\n<li>An\u00e1lisis de datos reales. En la operaci\u00f3n industrial, SiLK nos ayuda a identificar ciertos elementos y el analista debe responder a las preguntas: \u00ab\u00bfEncontramos lo que esper\u00e1bamos?\u00bb, \u00ab\u00bfSe ajusta esto a nuestra hip\u00f3tesis?\u00bb, \u00ab\u00bfC\u00f3mo reducir el n\u00famero de falsos positivos?\u00bb, \u00ab\u00bfC\u00f3mo mejorar la tasa de reconocimiento?\u00bb y as\u00ed sucesivamente.<\/li>\n<li>Mejora. En la etapa final, mejoramos lo realizado anteriormente: creamos plantillas, mejoramos y optimizamos el c\u00f3digo, reformulamos y aclaramos la hip\u00f3tesis, entre otros.<\/li>\n<\/ul>\n<p>Este ciclo tambi\u00e9n se aplicar\u00e1 a Cisco Stealthwatch, solo que este \u00faltimo automatiza los cinco pasos al m\u00e1ximo, reduciendo los errores del analista y aumentando la rapidez en la detecci\u00f3n de incidentes. Por ejemplo, en SiLK puedes enriquecer las estad\u00edsticas de red con datos externos sobre IP maliciosas mediante scripts escritos por ti, mientras que en Cisco Stealthwatch, esta es una funci\u00f3n integrada que te muestra inmediatamente una alerta si hay interacci\u00f3n en el tr\u00e1fico de red con direcciones IP de la lista negra.<\/p>\n<p>Si se sube en la pir\u00e1mide de \"costo\" del software de an\u00e1lisis de flujo, el SiLK gratuito se complementa con el ELK, que es condicionalmente gratuito y consta de tres componentes clave: Elasticsearch (indexaci\u00f3n, b\u00fasqueda y an\u00e1lisis de datos), Logstash (entrada\/salida de datos) y Kibana (visualizaci\u00f3n). A diferencia de SiLK, donde debes escribir todo t\u00fa mismo, ELK ya tiene muchas bibliotecas\/m\u00f3dulos listos (algunos de pago, otros no) que automatizan el an\u00e1lisis de telemetr\u00eda de red. Por ejemplo, el filtro GeoIP en Logstash permite vincular direcciones IP observadas a su ubicaci\u00f3n geogr\u00e1fica (esa funci\u00f3n est\u00e1 integrada en Stealthwatch).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK tambi\u00e9n tiene una comunidad bastante amplia que desarrolla componentes faltantes para esta soluci\u00f3n de monitoreo. Por ejemplo, para trabajar con Netflow, IPFIX y sFlow, puedes utilizar el m\u00f3dulo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, si no te satisface el M\u00f3dulo de Netflow de Logstash, que solo admite Netflow.<\/p>\n<p>Dando m\u00e1s rapidez en la recopilaci\u00f3n y b\u00fasqueda de flujo, ELK actualmente carece de rica anal\u00edtica integrada para la detecci\u00f3n de anomal\u00edas y amenazas en la telemetr\u00eda de red. Es decir, siguiendo el ciclo de vida descrito anteriormente, tendr\u00e1s que describir por ti mismo los modelos de violaciones y luego utilizarlos en el sistema operativo (no hay modelos integrados).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nExisten, por supuesto, extensiones m\u00e1s sofisticadas para ELK, que ya incluyen algunos modelos de detecci\u00f3n de anomal\u00edas en la telemetr\u00eda de red, pero tales extensiones tienen un costo y aqu\u00ed ya surge la pregunta de si realmente vale la pena: \u00bfes mejor crear un modelo similar por cuenta propia, comprar su implementaci\u00f3n para su herramienta de monitoreo o adquirir una soluci\u00f3n lista de la clase de An\u00e1lisis de Tr\u00e1fico de Red?<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRealmente no quiero entrar en la pol\u00e9mica sobre si es mejor gastar dinero y comprar una soluci\u00f3n lista para la monitorizaci\u00f3n de anomal\u00edas y amenazas en la telemetr\u00eda de red (por ejemplo, Cisco Stealthwatch) o resolverlo por uno mismo y ajustar tools como SiLK, ELK o nfdump u OSU Flow Tools (me refiero a los \u00faltimos dos de ellos). <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">habl\u00e9<\/a><\/noindex> Cada quien elige seg\u00fan sus propias motivaciones y hay razones v\u00e1lidas para optar por cualquiera de las dos opciones. Solo quer\u00eda mostrar que la telemetr\u00eda de red es una herramienta muy importante para garantizar la seguridad de la infraestructura interna y no debe ser descuidada, para no unirse a la lista de empresas cuyo nombre aparece en los medios junto con ep\u00edtetos como \"hackeada\", \"que no cumpl\u00eda con los requisitos de seguridad de la informaci\u00f3n\", \"que no se preocupa por la seguridad de sus datos y los de sus clientes\".<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara resumir, me gustar\u00eda enumerar algunos consejos clave a seguir al establecer la monitorizaci\u00f3n de la seguridad de la informaci\u00f3n en su infraestructura interna:<\/p>\n<ol>\n<li>\u00a1No se limite solo al per\u00edmetro! Utilice (y elija) la infraestructura de red no solo para transmitir tr\u00e1fico de un punto A a un punto B, sino tambi\u00e9n para abordar cuestiones de ciberseguridad.<\/li>\n<li>Estudie los mecanismos existentes de monitorizaci\u00f3n de seguridad de la informaci\u00f3n en su equipo de red y util\u00edcelos.<\/li>\n<li>Para la monitorizaci\u00f3n interna, prefiera el an\u00e1lisis de telemetr\u00eda: este m\u00e9todo permite detectar hasta el 80-90% de todos los incidentes de seguridad de la informaci\u00f3n, haciendo lo que no es posible con la captura de paquetes de red y ahorrando espacio para almacenar todos los eventos de seguridad de la informaci\u00f3n.<\/li>\n<li>Para la monitorizaci\u00f3n de flujos, utilice Netflow v9 o IPFIX: proporcionan m\u00e1s informaci\u00f3n en el contexto de seguridad y permiten monitorizar no solo IPv4, sino tambi\u00e9n IPv6, MPLS, etc.<\/li>\n<li>Utilice un protocolo de flujo no muestreado, ya que brinda m\u00e1s informaci\u00f3n para la detecci\u00f3n de amenazas. Por ejemplo, Netflow o IPFIX.<\/li>\n<li>Verifique la carga de su equipo de red; podr\u00eda no ser capaz de manejar tambi\u00e9n el protocolo flow. Entonces, considere el uso de sensores virtuales o un Netflow Generation Appliance.<\/li>\n<li>Implemente el control principalmente a nivel de acceso; esto le dar\u00e1 la capacidad de ver el 100% de todo el tr\u00e1fico.<\/li>\n<li>Si no tiene opciones y utiliza equipos de red rusos, elija aquellos que soporten protocolos flow o que tengan puertos SPAN\/RSPAN.<\/li>\n<li>Combine sistemas de detecci\u00f3n\/preventivos de intrusiones ataques en los bordes y sistemas de an\u00e1lisis de flujo en la red interna (incluyendo en la nube).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn cuanto al \u00faltimo consejo, me gustar\u00eda presentar una ilustraci\u00f3n que ya he mencionado anteriormente. Pueden ver que si antes el servicio de seguridad Cisco constru\u00eda casi todo su sistema de monitoreo de seguridad basado en sistemas de detecci\u00f3n de intrusiones y m\u00e9todos de firmas, ahora solo representa el 20% de los incidentes. Otro 20% corresponde a sistemas de an\u00e1lisis de flujo, lo que indica que estas soluciones no son un capricho, sino una herramienta real en la actividad de los servicios de seguridad de las empresas modernas. Adem\u00e1s, contar con su infraestructura de red para implementarlas es lo m\u00e1s importante, ya que puede proteger su inversi\u00f3n al incluir tambi\u00e9n funciones de monitoreo de seguridad en la red.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de flujo como herramienta para la monitorizaci\u00f3n de la seguridad de redes internas\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo he abordado el tema de la respuesta ante anomal\u00edas o amenazas detectadas en los flujos de red, pero creo que est\u00e1 claro que el monitoreo no debe finalizar solo con la detecci\u00f3n de amenazas. Debe seguir una respuesta, preferiblemente en modo autom\u00e1tico o automatizado. Pero ese es un tema para otra discusi\u00f3n.<\/p>\n<p>Informaci\u00f3n adicional:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html\">Descripci\u00f3n de Cisco IOS Netflow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/community.cisco.com\/t5\/security-documents\/netflow-support-matrix\/ta-p\/3644638\">Matriz de soporte de Netflow en diversas soluciones de Cisco<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/td\/docs\/security\/stealthwatch\/netflow\/Cisco_NetFlow_Configuration.pdf\">Gu\u00eda para configurar Netflow en diversas plataformas de Cisco<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">Comunidad sFlow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ciscolive.com\/c\/dam\/r\/ciscolive\/us\/docs\/2015\/pdf\/LTRSEC-3336.pdf\">Laboratorio sobre el uso de Stealthwatch, SiLK y ELK para el an\u00e1lisis de Netflow en t\u00e9rminos de seguridad<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">Sitio web de SiLK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Gu\u00eda de trescientos p\u00e1ginas sobre el uso de SiLK con muchos ejemplos<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">M\u00f3dulo Netflow de Logstash<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.cisco.com\/security\/step-by-step-setup-of-elk-for-netflow-analytics\">Gu\u00eda paso a paso de Cisco para analizar Netflow en ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">An\u00e1lisis de NetFlow v.9 Cisco ASA con Logstash (ELK)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Soluci\u00f3n Cisco Stealthwatch<\/a><\/noindex><\/li>\n<\/ul>\n<p>PD: Si le resulta m\u00e1s f\u00e1cil captar lo que se ha escrito arriba a escuchar, puede ver una presentaci\u00f3n de una hora que sirvi\u00f3 de base para esta nota.<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"ncDRZsueETo\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/ncDRZsueETo\/hqdefault.jpg\" alt=\"Reproducir video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/464601\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439. \u0410 \u0435\u0441\u043b\u0438 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0443\u0442\u043e\u0447\u043d\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u0438 \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c, \u043a\u0430\u043a \u0432\u044b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0432\u0430\u0435\u0442\u0435 \u0430\u0442\u0430\u043a\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u043e\u0442\u0432\u0435\u0442\u043e\u043c \u0431\u0443\u0434\u0435\u0442, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u043d\u0438\u0435 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0430\u0442\u0430\u043a (intrusion detection systems, IDS). \u0418 \u0442\u043e, \u0447\u0442\u043e \u0431\u044b\u043b\u043e \u0435\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37437","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Protocolos Flow como herramienta para la monitorizaci\u00f3n de la seguridad de la red interna | ProHoster","description":"Cuando se trata de la monitorizaci\u00f3n de la seguridad de una red corporativa o gubernamental interna, muchos la asocian con el control de filtraciones de informaci\u00f3n y la implementaci\u00f3n de soluciones DLP.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:17:38+00:00","article:modified_time":"2019-10-31T19:17:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37437","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 17:49:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:26:28","updated":"2026-01-23 17:49:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}