En 2010 la empresa Había 50 servidores y un modelo de red simple: backend, frontend y firewall. La cantidad de servidores creció, el modelo se volvió más complejo: preparación, VLAN aisladas con ACL, luego VPN con VRF, VLAN con ACL en L2, VRF con ACL en L3. ¿La cabeza da vueltas? Será más divertido más adelante.
Cuando había 16 servidores, se hizo imposible trabajar sin lágrimas con tantos segmentos heterogéneos. Entonces se nos ocurrió otra solución. Tomamos la pila de Netfilter, le agregamos Consul como fuente de datos y obtuvimos un firewall distribuido rápidamente. Reemplazaron las ACL en los enrutadores y las usaron como firewall externo e interno. Para gestionar dinámicamente la herramienta, desarrollamos el sistema BEFW, que se utilizó en todas partes: desde gestionar el acceso de los usuarios a la red del producto hasta aislar segmentos de red entre sí.
Él le dirá cómo funciona todo y por qué debería examinar más de cerca este sistema. Iván Agarkov () es el jefe del grupo de seguridad de infraestructura de la división de Mantenimiento en el centro de desarrollo de la empresa en Minsk. Ivan es fanático de SELinux, ama Perl y escribe código. Como jefe del grupo de seguridad de la información, trabaja periódicamente con registros, copias de seguridad e investigación y desarrollo para proteger Wargaming de los piratas informáticos y garantizar el funcionamiento de todos los servidores de juegos de la empresa.
La información histórica
Antes de contarles cómo lo hicimos, les diré cómo llegamos a esto en primer lugar y por qué era necesario. Para ello, retrocedamos 9 años: 2010, acaba de aparecer World of Tanks. Wargaming tenía aproximadamente 50 servidores.
Gráfico de crecimiento del servidor de la empresa.
Teníamos un modelo de red. Para esa época era óptimo.
Modelo de red en 2010.
Hay tipos malos en el frente que quieren atacarnos, pero tiene un firewall. No hay firewall en el backend, pero hay 50 servidores allí, los conocemos a todos. Todo funciona bien.
En 4 años, la flota de servidores se multiplicó por 100, hasta 5000. Aparecieron las primeras redes aisladas: en fase de puesta en escena: no podían entrar en producción y, a menudo, se ejecutaban allí cosas que podían ser peligrosas.
Modelo de red en 2014.
Por inercia, utilizamos las mismas piezas de hardware y todo el trabajo se realizó en VLAN aisladas: en las VLAN se escriben ACL, que permiten o niegan algún tipo de conexión.
En 2016, el número de servidores llegó a 8000. Wargaming absorbió otros estudios y aparecieron redes de afiliados adicionales. Parecen ser nuestros, pero no del todo: la VLAN a menudo no funciona para los socios, hay que usar VPN con VRF, el aislamiento se vuelve más complicado. La mezcla aislante ACL creció.
Modelo de red en 2016.
A principios de 2018, el parque de máquinas había aumentado a 16 000. Había 6 segmentos y no contamos el resto, incluidos los cerrados en los que se almacenaban datos financieros. Han aparecido redes de contenedores (Kubernetes), DevOps, redes en la nube conectadas vía VPN, por ejemplo, desde un IVS. Había muchas reglas, era doloroso.
Modelo de red y métodos de aislamiento en 2018.
Para el aislamiento utilizamos: VLAN con ACL en L2, VRF con ACL en L3, VPN y mucho más. Demasiado.
Problemas
Todo el mundo vive con ACL y VLAN. ¿Qué ocurre? Esta pregunta será respondida por Harold, ocultando el dolor.
Hubo muchos problemas, pero fueron cinco enormes.
- Aumento geométrico de precio para nuevas reglas. Cada nueva regla tardaba más en agregarse que la anterior, porque primero era necesario ver si ya existía dicha regla.
- Sin firewall dentro de los segmentos. Los segmentos estaban de alguna manera separados entre sí y ya no había suficientes recursos en su interior.
- Las reglas se aplicaron durante mucho tiempo. Los operadores podrían escribir una regla local a mano en una hora. La global tardó varios días.
- Dificultades con las reglas de auditoría.. Más precisamente, no fue posible. Las primeras reglas se redactaron en 2010 y la mayoría de sus autores ya no trabajaban para la empresa.
- Bajo nivel de control de infraestructura.. Éste es el principal problema: no sabíamos muy bien lo que estaba pasando en nuestro país.
Así se veía un ingeniero de redes en 2018 cuando escuchó: "Necesitamos más ACL".
Решения
A principios de 2018 se decidió hacer algo al respecto.
El precio de las integraciones crece constantemente. El punto de partida fue que los grandes centros de datos dejaron de admitir VLAN y ACL aisladas porque los dispositivos se quedaron sin memoria.
Solución: eliminamos el factor humano y automatizamos al máximo la provisión de acceso.
Las nuevas normas tardarán mucho en aplicarse. Solución: acelerar la aplicación de reglas, hacerla distribuida y paralela. Esto requiere un sistema distribuido para que las reglas se entreguen solas, sin rsync ni SFTP, a mil sistemas.
Sin firewall dentro de los segmentos. Un firewall dentro de segmentos empezó a llegarnos cuando aparecieron diferentes servicios dentro de una misma red. Solución: utilice un firewall a nivel de host: firewalls basados en host. En casi todos lados tenemos Linux y en todos lados tenemos iptables, esto no es un problema.
Dificultades con las reglas de auditoría. Solución: Mantenga todas las reglas en un solo lugar para su revisión y administración, de modo que podamos auditarlo todo.
Bajo nivel de control sobre la infraestructura. Solución: inventariar todos los servicios y accesos entre ellos.
Este es más un proceso administrativo que técnico. A veces tenemos entre 200 y 300 lanzamientos nuevos a la semana, especialmente durante promociones y días festivos. Además, esto es sólo para un equipo de nuestro DevOps. Con tantos lanzamientos, es imposible ver qué puertos, IP e integraciones se necesitan. Por lo tanto, necesitábamos gerentes de servicio especialmente capacitados que preguntaran a los equipos: "¿Qué hay allí y por qué lo mencionaste?"
Después de todo lo que lanzamos, un ingeniero de redes en 2019 empezó a verse así.
Consul
Decidimos que pondríamos todo lo que encontráramos con la ayuda de los administradores de servicios en Consul y desde allí escribiríamos reglas de iptables.
¿Cómo decidimos hacer esto?
- Recopilaremos todos los servicios, redes y usuarios.
- Creemos reglas de iptables basadas en ellas.
- Automatizamos el control.
- :
- Beneficio
Consul no es una API remota, puede ejecutarse en cada nodo y escribir en iptables. ¡Todo lo que queda es idear controles automáticos que limpien cosas innecesarias y la mayoría de los problemas se resolverán! El resto lo resolveremos sobre la marcha.
¿Por qué cónsul?
Ha demostrado su eficacia. En 2014-15, lo usamos como backend para Vault, en el que almacenamos contraseñas.
No pierde datos. Durante el tiempo de uso, Consul no perdió datos durante un solo accidente. Esta es una gran ventaja para un sistema de gestión de firewall.
Las conexiones P2P aceleran la propagación del cambio. Con P2P, todos los cambios se producen rápidamente, no es necesario esperar horas.
API REST conveniente. También consideramos Apache ZooKeeper, pero no tiene una API REST, por lo que tendrás que instalar muletas.
Funciona como Key Vault (KV) y como directorio (Service Discovery). Puede almacenar servicios, catálogos y centros de datos a la vez. Esto es conveniente no sólo para nosotros, sino también para los equipos vecinos, porque cuando creamos un servicio global, pensamos en grande.
Escrito en Go, que forma parte de la pila de Wargaming. Nos encanta este lenguaje, tenemos muchos desarrolladores de Go.
Potente sistema ACL. En Consul, puedes usar ACL para controlar quién escribe qué. Garantizamos que las reglas del firewall no se superpondrán con nada más y no tendremos problemas con esto.
Pero Consul también tiene sus inconvenientes.
- No escala dentro de un centro de datos a menos que tenga una versión comercial. Sólo es escalable por federación.
- Depende mucho de la calidad de la red y de la carga del servidor. Consul no funcionará correctamente como servidor en un servidor ocupado si hay retrasos en la red, por ejemplo, velocidad desigual. Esto se debe a las conexiones P2P y a los modelos de distribución de actualizaciones.
- Dificultad para monitorear la disponibilidad. En el estatus de Cónsul puede decir que todo está bien, pero murió hace mucho tiempo.
Resolvimos la mayoría de estos problemas usando Consul, razón por la cual lo elegimos. La empresa tiene planes para un backend alternativo, pero hemos aprendido a lidiar con los problemas y actualmente vivimos con Consul.
Cómo funciona el cónsul
Instalaremos de tres a cinco servidores en un centro de datos condicional. Uno o dos servidores no funcionarán: no podrán organizar un quórum y decidir quién tiene razón y quién no cuando los datos no coinciden. Más de cinco no tiene sentido, la productividad bajará.
Los clientes se conectan a los servidores en cualquier orden: los mismos agentes, solo que con la bandera server = false.
Después de esto, los clientes reciben una lista de conexiones P2P y establecen conexiones entre ellos.
A nivel global conectamos varios centros de datos. También conectan P2P y se comunican.
Cuando queremos recuperar datos de otro centro de datos, la solicitud va de servidor en servidor. Este esquema se llama Protocolo de siervo. El protocolo Serf, al igual que Consul, es desarrollado por HashiCorp.
Algunos datos importantes sobre Cónsul
Consul tiene documentación que describe cómo funciona. Sólo daré hechos seleccionados que vale la pena conocer.
Los servidores del cónsul seleccionan un maestro entre los votantes. Consul selecciona un maestro de la lista de servidores para cada centro de datos y todas las solicitudes van solo a él, independientemente de la cantidad de servidores. La congelación general no conduce a la reelección. Si el maestro no es seleccionado, nadie atiende las solicitudes.
¿Querías escalado horizontal? Lo siento, no.
Una solicitud a otro centro de datos va de un maestro a otro, independientemente del servidor al que llegue. El maestro seleccionado recibe el 100% de la carga, excepto la carga en solicitudes directas. Todos los servidores del centro de datos tienen una copia actualizada de los datos, pero solo uno responde.
La única forma de escalar es habilitar el modo obsoleto en el cliente.
En modo obsoleto, puede responder sin quórum. Este es un modo en el que renunciamos a la coherencia de los datos, pero leemos un poco más rápido de lo habitual y cualquier servidor responde. Naturalmente, grabando sólo a través del master.
Cónsul no copia datos entre centros de datos. Cuando se crea una federación, cada servidor tendrá solo sus propios datos. Para otros, siempre recurre a otra persona.
La atomicidad de las operaciones no está garantizada fuera de una transacción.. Recuerda que no eres el único que puede cambiar las cosas. Si lo desea de otra manera, realice una transacción con candado.
Las operaciones de bloqueo no garantizan el bloqueo.. La solicitud va de maestro a maestro, y no directamente, por lo que no hay garantía de que el bloqueo funcione cuando bloquea, por ejemplo, en otro centro de datos.
ACL tampoco garantiza el acceso (en muchos casos). Es posible que la ACL no funcione porque está almacenada en un centro de datos de la federación: en el centro de datos de la ACL (DC principal). Si el DC no te responde, la ACL no funcionará.
Un maestro congelado hará que toda la federación se congele. Por ejemplo, hay 10 centros de datos en una federación, uno tiene una red defectuosa y un maestro falla. Todos los que se comunican con él quedarán atrapados en un círculo: hay una solicitud, no hay respuesta, el hilo se congela. No hay forma de saber cuándo sucederá esto, sólo en una hora o dos caerá toda la federación. No hay nada que puedas hacer al respecto.
El estado, el quórum y las elecciones se manejan mediante un hilo separado. La reelección no se producirá, el estado no mostrará nada. Crees que tienes un cónsul vivo, preguntas y no pasa nada, no hay respuesta. Al mismo tiempo, el estado muestra que todo está bien.
Nos encontramos con este problema y tuvimos que reconstruir partes específicas de los centros de datos para evitarlo.
La versión empresarial de Consul Enterprise no tiene algunas de las desventajas anteriores. Tiene muchas funciones útiles: selección de votantes, distribución, escalamiento. Sólo hay un "pero": el sistema de licencias para un sistema distribuido es muy caro.
Hacking de la vida rm -rf /var/lib/consul - una cura para todas las enfermedades del agente. Si algo no funciona para usted, simplemente elimine sus datos y descárguelos de una copia. Lo más probable es que Cónsul funcione.
ANTES
Ahora hablemos de lo que hemos agregado a Consul.
es un acrónimo de Bacuse de reciboEndFiraWtodo. Tuve que nombrar el producto de alguna manera cuando creé el repositorio para poder incluir las primeras confirmaciones de prueba. Este nombre permanece.
Plantillas de reglas
Las reglas están escritas en la sintaxis de iptables.
- -N ANTES
- -P CAÍDA DE ENTRADA
- -A ENTRADA -m estado—estado RELACIONADO,ESTABLECIDO -j ACEPTAR
- -A ENTRADA -i lo -j ACEPTAR
- -A ENTRADA -j ANTES
Todo entra en la cadena BEFW, excepto ESTABLISHED, RELATED y localhost. La plantilla puede ser cualquier cosa, esto es sólo un ejemplo.
¿Cómo es útil BEFW?
Servicios
Tenemos un servicio, siempre tiene un puerto, un nodo en el que se ejecuta. Desde nuestro nodo podremos preguntar localmente al agente y saber que tenemos algún tipo de servicio. También puedes poner etiquetas.
Cualquier servicio que esté ejecutándose y registrado con Consul se convierte en una regla de iptables. Tenemos SSH: puerto abierto 22. El script Bash es simple: curl e iptables, no se necesita nada más.
Clientela
¿Cómo abrir el acceso no a todos, sino de forma selectiva? Agregue listas de IP al almacenamiento de KV por nombre de servicio.
Por ejemplo, queremos que todos los usuarios de la décima red puedan acceder al servicio SSH_TCP_22. ¿Agregar un pequeño campo TTL? y ahora tenemos permisos temporales, por ejemplo, por un día.
Accesos
Conectamos servicios y clientes: tenemos un servicio, el almacenamiento KV está listo para cada uno. Ahora damos acceso no a todos, sino de forma selectiva.
Группы
Si escribimos miles de IP para acceder cada vez, nos cansaremos. Pensemos en agrupaciones: un subconjunto separado en KV. Llamémoslo Alias (o grupos) y almacenemos grupos allí según el mismo principio.
Conectémonos: ahora podemos abrir SSH no específicamente para P2P, sino para un grupo completo o varios grupos. De la misma manera, existe TTL: puede agregarlo a un grupo y eliminarlo temporalmente.
integración
Nuestro problema es el factor humano y la automatización. Hasta ahora lo hemos solucionado de esta manera.
Trabajamos con Puppet y les transferimos todo lo relacionado con el sistema (código de aplicación). Puppetdb (PostgreSQL normal) almacena una lista de servicios que se ejecutan allí y se pueden encontrar por tipo de recurso. Allí podrá averiguar quién presenta la solicitud y dónde. También contamos con un sistema de solicitud de extracción y solicitud de fusión para esto.
Escribimos befw-sync, una solución simple que ayuda a transferir datos. En primer lugar, Puppetdb accede a las cookies de sincronización. Allí se configura una API HTTP: solicitamos qué servicios tenemos, qué hay que hacer. Luego hacen una solicitud al Cónsul.
¿Hay integración? Sí: escribieron las reglas y permitieron que se aceptaran Pull Requests. ¿Necesita un puerto determinado o agregar un host a algún grupo? Solicitud de extracción, revisión: no más "Busque otras 200 ACL e intente hacer algo al respecto".
Optimización
Hacer ping al localhost con una cadena de reglas vacía tarda 0,075 ms.
Agreguemos 10 direcciones de iptables a esta cadena. Como resultado, el ping aumentará 000 veces: iptables es completamente lineal, procesar cada dirección lleva algún tiempo.
Para un firewall donde migramos miles de ACL, tenemos muchas reglas y esto introduce latencia. Esto es malo para los protocolos de juego.
Pero si ponemos 10 direcciones en ipset El ping incluso disminuirá.
El punto es que "O" (complejidad del algoritmo) para ipset siempre es igual a 1, sin importar cuántas reglas haya. Es cierto que existe una limitación: no puede haber más de 65535 reglas. Por ahora vivimos con esto: puedes combinarlas, expandirlas, crear dos ipsets en uno.
Almacenamiento
Una continuación lógica del proceso de iteración es almacenar información sobre los clientes del servicio en ipset.
Ahora tenemos el mismo SSH y no escribimos 100 IP a la vez, sino que configuramos el nombre del ipset con el que necesitamos comunicarnos y la siguiente regla DROP. Se puede convertir en una regla “Quien no está aquí, DROP”, pero es más claro.
Ahora tenemos reglas y conjuntos. La tarea principal es crear un conjunto antes de escribir la regla, porque de lo contrario iptables no escribirá la regla.
Esquema general
En forma de diagrama, todo lo que dije se ve así.
Nos comprometemos con Puppet, todo se envía al host, servicios aquí, ipset allá, y cualquiera que no esté registrado allí no está permitido.
Permiten negar
Para salvar rápidamente el mundo o desactivar rápidamente a alguien, al comienzo de todas las cadenas creamos dos ipsets: rules_allow и rules_deny. ¿Cómo funciona?
Por ejemplo alguien está creando una carga en nuestra Web con bots. Anteriormente, había que encontrar su IP en los registros, llevarla a los ingenieros de red para que pudieran encontrar la fuente del tráfico y prohibirlo. Parece diferente ahora.
Se lo enviamos al Cónsul, esperamos 2,5 segundos y listo. Dado que Consul distribuye rápidamente a través de P2P, funciona en todas partes, en cualquier parte del mundo.
Una vez detuve por completo WOT debido a un error con el firewall. rules_allow - este es nuestro seguro contra tales casos. Si cometimos un error en algún lugar con el firewall, algo está bloqueado en algún lugar, siempre podemos enviar un condicional 0.0/0para recoger todo rápidamente. Posteriormente arreglaremos todo a mano.
Otros conjuntos
Puedes agregar cualquier otro conjunto en el espacio. $IPSETS$.
¿Para qué? A veces alguien necesita ipset, por ejemplo, para emular el apagado de alguna parte del clúster. Cualquiera puede traer sus juegos, nombrarlos y serán recogidos por el Cónsul. Al mismo tiempo, los conjuntos pueden participar en las reglas de iptables o actuar como un equipo. NOOP: El demonio mantendrá la coherencia.
Miembros
Anteriormente era así: el usuario se conectaba a la red y recibía los parámetros a través del dominio. Antes de la llegada de los firewalls de nueva generación, Cisco no sabía entender dónde estaba el usuario y dónde estaba la IP. Por lo tanto, el acceso se concedió únicamente a través del nombre de host de la máquina.
¿Qué hicimos? Nos quedamos atascados en el momento en que recibimos la dirección. Por lo general, es dot1x, Wi-Fi o VPN; todo pasa por RADIUS. Para cada usuario, creamos un grupo por nombre de usuario y colocamos en él una IP con un TTL igual a su dhcp.lease; tan pronto como caduque, la regla desaparecerá.
Ahora podemos abrir el acceso a servicios, como a otros grupos, mediante nombre de usuario. Hemos eliminado la molestia de los nombres de host cuando cambian y hemos quitado la carga a los ingenieros de redes porque ya no necesitan a Cisco. Ahora los propios ingenieros registran el acceso en sus servidores.
Изоляция
Al mismo tiempo comenzamos a desmontar el aislamiento. Los gerentes de servicio hicieron un inventario y analizamos todas nuestras redes. Los dividimos en los mismos grupos y en los servidores necesarios se agregaron grupos, por ejemplo, para denegar. Ahora el mismo aislamiento escénico termina en las reglas: negación de la producción, pero no en la producción misma.
El esquema funciona de forma rápida y sencilla: eliminamos todas las ACL de los servidores, descargamos el hardware y reducimos la cantidad de VLAN aisladas.
control de integridad
Anteriormente, teníamos un activador especial que informaba cuando alguien cambiaba una regla de firewall manualmente. Estaba escribiendo un linter enorme para verificar las reglas del firewall, fue difícil. La integridad ahora está controlada por BEFW. Se asegura celosamente de que las reglas que establece no cambien. Si alguien cambia las reglas del firewall, todo volverá a cambiar. “Configuré rápidamente un proxy para poder trabajar desde casa”: ya no existen opciones de este tipo.
BEFW controla el ipset de los servicios y enumera en befw.conf las reglas de los servicios en la cadena BEFW. Pero no monitorea otras cadenas, reglas ni otros ipsets.
Protección contra choques
BEFW siempre almacena el último buen estado conocido directamente en la estructura binaria state.bin. Si algo sale mal, siempre vuelve a este estado.bin.
Este es un seguro contra el funcionamiento inestable del Cónsul, cuando no envió datos o alguien cometió un error y utilizó reglas que no se pueden aplicar. Para garantizar que no nos quedemos sin un firewall, BEFW volverá al estado más reciente si ocurre un error en cualquier etapa.
En situaciones críticas, esto es una garantía de que nos quedará un firewall funcional. Abrimos todas las redes grises con la esperanza de que el administrador venga y lo solucione. Algún día pondré esto en las configuraciones, pero ahora solo tenemos tres redes grises: 10/8, 172/12 y 192.168/16. Dentro de nuestro Cónsul, esta es una característica importante que nos ayuda a desarrollarnos aún más.
Demostración: durante el informe, Ivan demuestra el modo de demostración de BEFW. Es más fácil ver la demostración. . Código fuente de demostración disponible .
Trampas
Te contaré sobre los errores que encontramos.
ipset agregar conjunto 0.0.0.0/0. ¿Qué pasa si agregas 0.0.0.0/0 a ipset? ¿Se agregarán todas las IP? ¿Estará disponible el acceso a Internet?
No, obtendremos un error que nos costará dos horas de inactividad. Además, el error no ha funcionado desde 2016, está ubicado en RedHat Bugzilla con el número #1297092 y lo encontramos por accidente, según un informe de un desarrollador.
Ahora es una regla estricta en BEFW que 0.0.0.0/0 se convierte en dos direcciones: 0.0.0.0/1 и 128.0.0.0/1.
conjunto de restauración ipset <archivo. ¿Qué hace ipset cuando se lo dices? restore? ¿Crees que funciona igual que iptables? ¿Recuperará datos?
Nada de eso: se fusiona y las direcciones antiguas no van a ninguna parte, no bloquea el acceso.
Encontramos un error al probar el aislamiento. Ahora existe un sistema bastante complejo - en lugar de restore llevado a cabo create tempentonces restore flush temp и restore temp. Al final del intercambio: por la atomicidad, porque si lo haces primero flush y en este momento llega algún paquete, será descartado y algo saldrá mal. Entonces hay un poco de magia negra ahí.
cónsul kv get -datacenter=other. Como dije, creemos que estamos solicitando algunos datos, pero obtendremos datos o un error. Podemos hacer esto localmente a través de Consul, pero en este caso ambos se congelarán.
El cliente Consul local es un contenedor de la API HTTP. Pero simplemente se cuelga y no responde a Ctrl+C, o Ctrl+Z, ni nada, solo kill -9 en la siguiente consola. Nos encontramos con esto cuando estábamos construyendo un grupo grande. Pero aún no tenemos una solución; nos estamos preparando para corregir este error en Consul.
El líder del cónsul no responde. Nuestro maestro en el centro de datos no responde, pensamos: "¿Quizás el algoritmo de reselección funcione ahora?"
No, no funcionará y el seguimiento no mostrará nada: el cónsul dirá que hay un índice de compromiso, que se ha encontrado un líder, que todo está bien.
¿Cómo nos enfrentamos a esto? service consul restart en cron cada hora. Si tienes 50 servidores, no es gran cosa. Cuando haya 16, entenderás cómo funciona.
Conclusión
Como resultado, recibimos las siguientes ventajas:
- Cobertura del 100% de todas las máquinas Linux.
- Velocidad
- Automatización.
- Liberamos de la esclavitud a los ingenieros de hardware y redes.
- Han aparecido posibilidades de integración casi ilimitadas: incluso con Kubernetes, incluso con Ansible, incluso con Python.
Contras: Cónsul, con lo que ahora tenemos que vivir, y el altísimo coste del error. Como ejemplo, una vez a las 6 de la tarde (horario de máxima audiencia en Rusia) estaba editando algo en las listas de redes. En ese momento estábamos construyendo aislamiento en BEFW. Cometí un error en alguna parte, parece que indiqué la máscara incorrecta, pero todo cayó en dos segundos. Se enciende el monitor, la persona de apoyo de turno llega corriendo: “¡Lo tenemos todo!” El jefe del departamento se puso gris cuando explicó al negocio por qué sucedió esto.
El coste del error es tan alto que hemos ideado nuestro propio y complejo procedimiento de prevención. Si implementa esto en un sitio de producción grande, no necesita darles un token maestro a través de Consul a todos. Esto terminará mal.
Costo. Escribí código solo durante 400 horas. Mi equipo de 4 personas dedica 10 horas al mes a dar soporte a todos. Comparado con el precio de cualquier firewall de nueva generación, es gratis.
Planes. El plan a largo plazo es encontrar transporte alternativo para reemplazar o complementar a Cónsul. Quizás sea Kafka o algo parecido. Pero en los próximos años viviremos de Cónsul.
Planes inmediatos: integración con Fail2ban, con monitorización, con nftables, posiblemente con otras distribuciones, métricas, monitorización avanzada, optimización. El soporte de Kubernetes también está en los planes, porque ahora tenemos varios clusters y el deseo.
Más de los planes:
- buscar anomalías en el tráfico;
- gestión de mapas de red;
- soporte de Kubernetes;
- montaje de paquetes para todos los sistemas;
- Interfaz de usuario web.
Trabajamos constantemente en ampliar la configuración, aumentar las métricas y la optimización.
Únase al proyecto. El proyecto resultó genial, pero, lamentablemente, sigue siendo un proyecto de una sola persona. Ven a e intenta hacer algo: comprometerte, probar, sugerir algo, dar tu valoración.
Mientras tanto nos estamos preparando para , que tendrá lugar los días 6 y 7 de abril en San Petersburgo, e invitamos a los desarrolladores de sistemas de alta carga . Los oradores experimentados ya saben qué hacer, pero para aquellos nuevos en la oratoria recomendamos al menos . Participar en la conferencia como ponente tiene una serie de ventajas. Puedes leer cuáles, por ejemplo, al final. .
Fuente: habr.com