No quiero renunciar al título. Después de todo, realiza su tarea: llama la atención. Le pido sinceramente que no se enoje si el contenido del artículo no ha cumplido con sus expectativas. Ahora es el momento "Dichos materiales", dijeron, "deben publicar en foros para aficionados, y en Habr solo la audiencia de TI altamente inteligente habla sobre cosas que nunca necesita comprender y no necesita tratar de comprender". Sin embargo, ¡Gloria a Habru! El es bastante democrático.
Algo me llamó la atención sobre el tema de la seguridad de la red en términos de análisis del tráfico de red y detección de actividad de red no autorizada (en adelante, la NSA).
Aspectos de la NSA que me interesan:
- escaneo no autorizado de recursos (puertos, destinos web) de la red protegida (en adelante - AP) desde una red abierta (en adelante - OS);
- - tráfico no autorizado de / a AP. Esta es una actividad de red independiente de aplicaciones;
- inserción no autorizada de contenido inapropiado (en adelante, NK). Esto es publicidad, contenido de contenido dudoso.
- Tipos conocidos de ataques a la red (en adelante, CA).
Lo que no me interesa hasta ahora: todo lo que no concierne a la red. Esta protección antivirus afecta directamente a estaciones de trabajo y servidores, correo no deseado, descifrado de contraseñas, etc. etc.
¿Por qué decidí reinventar la rueda? Después de todo, hay mucho hierro y software que parece realizar las mismas funciones y parece no estar mal. Pero esta es la pregunta: gastamos mucho dinero en superpoderes hiperconvergentes de la próxima generación, pero no tiene sentido. Llegó una actualización y falló todas las PC. Los usuarios se sientan con los derechos de los administradores, introducen anuncios en los navegadores y capturan ransomware. "Oh, estamos cerrados hoy por razones técnicas", debe decir el dueño del negocio. Los administradores lanzan un servidor nuevo en la red para actualizar con todos los puertos abiertos, se "actualiza como debería" inmediatamente. Y luego comienza a ralentizar la red, el dominio cae en spammers y otras delicias de la vida de TI. Bueno, Business está tratando de pagarles a los administradores para que se muden. Se mueven, pero no por mucho tiempo, se acostumbran. Todos saben que los incidentes de TI siempre ocurren repentinamente, como el invierno, para los servicios públicos. En cuanto al sector público, aquí, como de costumbre, "tontos y caminos". Por un lado, existen grandes gastos para la "modernización de la red", la compra de equipos caros, que no pueden causar otra cosa que una sospecha razonable de recortes presupuestarios. Por otro lado, bajos salarios para los especialistas de TI, lo que lleva a la rotación del personal y a un bajo nivel general de administradores profesionales. Como resultado, tenemos equipos caros y un estudiante que no sabe cómo, no sabe y no quiere saber qué hacer con esto. Es decir, el problema de seguridad no está en el hardware. El factor humano es lo que determina la seguridad general de los sistemas.
¿Por qué soy yo? Además, será interesante para el dueño de cada negocio tener un "administrador" que realice sus tareas igualmente bien las 24 horas del día, los 7 días de la semana, prácticamente "para la comida".
Este es exactamente el tipo de "administrador de hierro" que quiero implementar.
Decidí comenzar con la seguridad de la red. Limitar o excluir la influencia externa en el AP ya es el 50% del caso.
Entonces, el concepto general:
Las principales condiciones iniciales (¿ideales?):
- Bajo costo La pieza de hierro en la versión básica debe ser asequible para todas las categorías, desde un usuario individual con una PC y superior.
- Una pieza de hierro no debe requerir la atención constante de personal calificado para llevar a cabo sus tareas. Establecer y olvidar.
- La pieza de hierro debe reemplazarse fácilmente, sin requerir configuración adicional.
- El trozo de hierro debe ser interactivo: informar a un círculo predeterminado de personas sobre las amenazas actuales o sospechadas, su condición y tomar decisiones de forma independiente en función de un análisis de la situación. Es decir, no es el administrador quien debe mirar constantemente en el registro, pero el Iron debe informar que algo salió mal y lo que hizo para solucionarlo "mal".
- La interfaz de interacción con el Iron debe ser simple y comprensible incluso para un especialista en TI novato. Sin consolas ni expresiones regulares. Deja el cielo a los pájaros.
Esto se refiere a los objetivos estratégicos. Ahora de vuelta a la tierra. Deje que Zhelezka consista en Recolectores que recopilen información y el Centro de Análisis y Toma de Decisiones (en adelante, CACR). Hay algunas analogías con Smart Home, IoT. Que sea "Pulpo inteligente" (fu, asqueroso). ¿Pero por qué no? Parece que, después de todo, los coleccionistas son tentáculos y el cerebro es DACR
Hay varias opciones para DACR:
- Integrado: colector y DAC en la misma pieza de hierro.
- Local: trabaja con una lista limitada de equipos. Digamos dentro de la misma organización o territorio.
- Global: un recurso de Internet que funciona con recopiladores dentro de Internet.
- Regional (opción): para distribuir la carga de Global.
Todos los DACA de nivel inferior pueden interactuar con el Global DAC, que almacena la base de datos más completa de las características de la NSA.
La primera acción. Creamos un CARP-Collector integrado para monitorear la NSA.
¿Qué es el NSA Collector en la etapa actual? Esto es esencialmente una computadora Linux ubicada en un paquete de 1U. El colector tiene 3 interfaces de red. Dos está activado en toda la red. Una interfaz de gestión. DAC se encuentra en la misma plataforma.
Aquí está el diagrama de cableado actual:
Cualquier interacción del recopilador externo es solo a través de la interfaz de control. Para el tráfico de Internet, el recopilador es transparente.
Dado que ahora estamos desarrollando el algoritmo básico para este stand, es suficiente. Por supuesto, el producto terminado tendrá hardware más avanzado y herramientas de resistencia.
¿Qué hace el coleccionista? Recoge determinadas partes del tráfico. Encabezados y, si es necesario, contenido del paquete. Esto es configurable por las reglas. No tiene sentido recoger todo el tráfico. Los datos de tráfico durante un corto período de tiempo (dependiendo de la carga y el volumen del disco de trabajo, semana-mes) se almacenan en el recopilador. Por lo tanto, el recopilador puede actuar como un reemplazo simultáneo de la fuente, el recopilador y el sistema de visualización de estadísticas del tipo Netflow. Por supuesto, dado que el recopilador contiene información sobre cada sesión, no está destinado a almacenar estadísticas durante largos períodos de tiempo. Si esto es necesario, las estadísticas se pueden volcar en el almacenamiento de red o en una unidad asignada en forma de archivos y, en el futuro, analizarse y visualizarse mediante DAC.
El coleccionista no es estúpido. Analiza el tráfico en función de las reglas definidas por el DAC y envía información al DAC en caso de disparadores de filtro definidos desde el DAC. Además, el recopilador filtra el tráfico por sí solo.
Algo asi.
Mientras trabaja en el recopilador, surgió la idea de cargarlo con otras funciones. No hablaré sobre todas las funciones planificadas. Pero existe el deseo de integrar el servidor y el recopilador del recopilador SNMP Trap en el recopilador SYSLOG. Esto es necesario, incluso para analizar la correlación de algunos eventos.
Como subproducto, un producto comercial, ¿qué es lo malo que se puede decir, una pieza de hardware que puede, de forma inmediata, administrar el tráfico, recopilar registros, estadísticas de red, trampas y mostrar todo esto de una manera simple y comprensible con notificación de eventos?
El proyecto está abierto a la participación.
Si alguien tiene sus propios desarrollos interesantes sobre el tema de SYSLOG, escriba SNMP al PM, cree un producto conjunto.
Condiciones basicas:
- No "basado en ...", solo propio, único, y si hay un front-end, ¡definitivamente es fácil de usar! Para que puedas trabajar sin teclado. Sin frenos o curvas Java. Zabbix y Logstash también van a Kibane. C, Python, Perl, PHP, HTML, CSS, JS son bienvenidos (limpio, sin marco de trabajo. Incluso sin jQuery, sí).
- Orientación solo a SO y navegadores modernos. No hay compatibilidad con MS-DOS en IBM XT e Internet Explorer 1.0.
- Solo para Linux.
Las ideas de negocios son bienvenidas, pero este no es el punto. En esta etapa, se necesitan ideas técnicas, cerebro y tiempo. Si es una pieza de hierro digna, la forma de archivar y vender se decidirá por sí misma.
Para una comunidad altamente inteligente, propongo un rompecabezas del Coleccionista (él mismo aún no lo ha decidido):
El circuito inicial es como en la figura anterior. El enrutador está conectado al ISP a través de PPPoE y la dirección 91.122.49.173 en él. La dirección ya está resaltada en artículos anteriores. Pero esto es bueno para las pruebas, hay un interés constante.
Esto es lo que mostró el coleccionista:
El marcador rojo es un ejemplo de una NSA. En este caso, el signo es que ni la dirección de origen ni la dirección de destino pertenecen al AP. UDP, puerto de destino 5000. El tema de los troyanos es bien conocido. Pero el AP solo tiene una dirección PAT externa (91.122.49.173). Es decir, espero que en el canal del enrutador ISP solo vea los paquetes cuya dirección de origen o de destino sea la dirección externa del enrutador.
Veamos la historia de hoy:
Aquí vemos que, de acuerdo con el mismo esquema, los paquetes con una dirección de origen, pero con diferentes direcciones de destino vuelan a través de nuestro recopilador.
Cómo llega este tráfico aún no lo he descubierto. Si alguien tiene pensamientos, por favor escriba en los comentarios. Al encontrarse con una NSA de este tipo, el recopilador pone una trampa en este tráfico y recopila información más detallada sobre su próxima aparición, y luego lo prohíbe. Esto, por supuesto, es solo un caso. Solo para mí es inexplicable por ahora;
Saludos
R_voland.