Hola a todos. Este artículo está dirigido a aquellos que tienen muchos dispositivos Mikrotik y desean hacer la máxima unificación para no tener que conectarse a cada dispositivo por separado. En este artículo describiré un proyecto que, lamentablemente, no llegó a condiciones operativas debido a factores humanos. En resumen: más de 200 enrutadores, configuración rápida y capacitación del personal, unificación por regiones, filtrado de redes y hosts específicos, posibilidad de añadir reglas fácilmente a todos los dispositivos, registro y control de acceso.
Lo que se describe a continuación no pretende ser un caso cerrado, pero espero que te sea útil al planificar tus redes y minimizar errores. Es posible que algunos puntos y soluciones te parezcan no del todo correctos; si es así, escríbeme en los comentarios. La crítica en este caso será una experiencia que suma al conocimiento común. Por lo tanto, lector, mira los comentarios, puede que el autor haya cometido un error grave; la comunidad ayudará.
La cantidad de enrutadores es de 200-300, dispersos por diferentes ciudades con diversos niveles de calidad en la conexión a Internet. Es necesario presentar todo de manera atractiva y explicarlo claramente a los administradores locales sobre cómo funcionará todo.
Entonces, ¿por dónde debe comenzar cualquier proyecto? Por supuesto, con TLD.
- La organización del plan de redes en todas las sucursales de acuerdo con los requisitos del cliente, segmentación de redes (de 3 a 20 redes en las sucursales dependiendo del número de dispositivos).
- Configuración de dispositivos en cada sucursal. Verificación de la velocidad real de conexión del proveedor en diferentes condiciones de operación.
- Organización de la protección de dispositivos, gestión mediante lista blanca, detección automática de ataques con inclusión automática en la lista negra por un período de tiempo determinado, minimización del uso de diversos medios técnicos utilizados para interceptar el acceso al control y abandono del servicio.
- Organización de conexiones VPN seguras con filtrado de redes según los requisitos del cliente. Mínimo 3 conexiones VPN desde cada sucursal al centro.
- Basado en los puntos 1 y 2. Elegir los caminos óptimos para construir VPN resistentes a fallos. La tecnología de enrutamiento dinámico puede ser seleccionada por el ejecutor con justificación adecuada.
- Organización de priorización del tráfico según protocolos, puertos, hosts y otros servicios específicos que utiliza el cliente. (VOIP, hosts con servicios importantes)
- Organización del monitoreo y registro de eventos de los enrutadores para la respuesta del personal de soporte técnico.
Como entendemos, en algunos casos los requisitos se elaboran a partir de las demandas. Estas demandas las he formulado yo mismo, escuchando los problemas principales. Consideré la posibilidad de que la ejecución de estos puntos podría ser realizada por otra persona.
¿Qué herramientas se utilizarán para cumplir con estos requisitos?
- Stack ELK (después de un tiempo, se llegó a la conclusión de que en lugar de logstash se utilizará fluentd).
- Ansible. Para facilitar la administración y la división de accesos, utilizaremos AWX.
- GITLAB. Aquí no hay que explicar mucho. ¿Quién puede prescindir del control de versiones de nuestras configuraciones?
- PowerShell. Habrá un script sencillo para la generación inicial de la configuración.
- Doku wiki, para la redacción de documentación y guías. En este caso, utilizamos habr.com.
- El monitoreo se llevará a cabo a través de zabbix. Allí también se dibujará el esquema de conexiones para una comprensión general.
Momentos de configuración de EFK
En el primer punto, solo describiré la ideología según la que se construirán los índices. Hay muchos
artículos excelentes sobre la configuración y recepción de logs de dispositivos bajo el control de mikrotik.
Me detendré en algunos momentos:
1. Según el esquema, se debe pensar en la recepción de logs desde diferentes lugares y a través de diferentes puertos. Para ello, utilizaremos un agregador de logs. También queremos hacer gráficos universales para todos los enrutadores con la posibilidad de segmentación de acceso. Entonces, construiremos los índices de la siguiente manera:
aquí está un fragmento de la configuración con fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
De esta manera, podemos agrupar los enrutadores y segmentar de acuerdo al plan: mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. ¿Por qué complicarlo tanto? Entendemos que tendremos 200 o más dispositivos. No se puede controlar todo. Desde la versión 6.8 de elasticsearch, tenemos disponibles configuraciones de seguridad (sin necesidad de comprar licencia), por lo que podemos distribuir los derechos de visualización entre el personal de soporte técnico o administradores de sistemas locales.
Tablas, gráficos: aquí ya hay que acordar, ya sea usar algo uniforme o que cada uno lo haga como le sea más cómodo.
2. Sobre el registro. Si activamos el log en las reglas del firewall, entonces los nombres deben hacerse sin espacios. Se puede ver que, al utilizar una configuración simple en fluentd, podemos filtrar datos y crear paneles convenientes. En la imagen de abajo, mi enrutador doméstico.
3. Sobre el espacio ocupado y los logs. En promedio, con 1000 mensajes por hora, los logs ocupan entre 2 y 3 MB al día, lo cual, seamos sinceros, no es tanto. Versión de elasticsearch 7.5.
ANSIBLE.AWX
Afortunadamente, tenemos un módulo listo para routeros.
Mencioné AWX, pero los comandos a continuación son solo sobre ansible en su forma pura; creo que para aquellos que han trabajado con ansible, no habrá problemas utilizando la interfaz gráfica de awx.
Confieso que antes vi otras guías donde usaban ssh, y todos tenían diferentes problemas con el tiempo de respuesta y un montón de otros problemas. Reitero, no llegamos a la batalla, perciban esta información como un experimento que no llegó más allá de un stand de 20 enrutadores.
Necesitamos utilizar un certificado o una cuenta. Aquí depende de ustedes, yo prefiero los certificados. Un pequeño detalle sobre los permisos. Doy permisos de escritura, aunque no se podrá hacer ni siquiera un "reset config".
No debería haber problemas con la generación, copia del certificado e importación:
Resumen de comandosEn tu PC
ssh-keygen -t RSA, respondemos a las preguntas, guardamos la clave.
Copiamos en mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Previamente, hay que crear una cuenta y asignarle permisos.
Verificamos la conexión mediante el certificado.
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Escribimos vi /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
Y aquí un ejemplo de playbook: - name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
- name: add Work_sites
routeros_command:
commands:
- /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip firewall address-list add address=habr.com list=work_sites comment=for_habr
Como se puede ver en la configuración anterior, crear nuestros propios playbooks no es difícil. Solo es necesario dominar bien el cli de mikrotik. Imaginemos una situación en la que en todos los enrutadores necesitamos eliminar una lista de direcciones con ciertos datos, entonces:
Buscar y eliminar/ip firewal address-list remove [find where list=«gov.ru»]
No incluí aquí toda la lista del firewall intencionalmente, ya que será individual para cada proyecto. Pero puedo decir con certeza que solo deben usar la lista de direcciones.
Todo está claro con GITLAB. No me detendré en este punto. Todo está organizado en tareas, plantillas y controladores.
Powershell
Aquí habrá 3 archivos. ¿Por qué PowerShell? Se puede elegir cualquier herramienta para generar configuraciones, como mejor le parezca a cada uno. En este caso, todos tienen Windows en sus PCs, así que, ¿para qué hacerlo en bash, cuando PowerShell es más conveniente? A cada uno lo que le convenga.
El script en sí (sencillo y comprensible):[cmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)]
[string]$BWorknets,
[Parameter(Mandatory=$true)]
[string]$CWorknets,
[Parameter(Mandatory=$true)]
[string]$BVoipNets,
[Parameter(Mandatory=$true)]
[string]$CVoipNets,
[Parameter(Mandatory=$true)]
[string]$CClientss,
[Parameter(Mandatory=$true)]
[string]$BVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$CVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$NAMEROUTER,
[Parameter(Mandatory=$true)]
[string]$ServerCertificates,
[Parameter(Mandatory=$true)]
[string]$infile,
[Parameter(Mandatory=$true)]
[string]$outfile
)
Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Object {$_.Replace("CClients", $CClientss)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach-Object {$_.Replace("BVPNCLIENTS", $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Les pido disculpas, no puedo publicar todas las reglas ya que no quedaría bien. Pueden crear las reglas ustedes mismos siguiendo las mejores prácticas.
Por ejemplo, aquí hay una lista de enlaces que utilicé como referencia::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — aquí deben saber que al habilitar el fasttrack, las reglas de priorización y modelado de tráfico no funcionarán, lo que es útil para dispositivos de bajo rendimiento.
Abreviaturas sobre variables:Se tomaron como ejemplo las siguientes redes:
192.168.0.0/24 red de trabajo
172.22.4.0/24 red VOIP
10.0.0.0/24 red para clientes sin acceso a la red local
192.168.255.0/24 red VPN para grandes sucursales
172.19.255.0/24 red VPN para pequeñas sucursales
La dirección de la red consta de 4 números en decimal, o sea A.B.C.D, funciona de la misma manera para la sustitución; si al ejecutarlo pide B, entonces se debe ingresar para la red 192.168.0.0/24 el número 0, y para C = 0.
$EXTERNALIPADDRESS — dirección dedicada del proveedor.
$EXTERNALIPROUTE — ruta por defecto a la red 0.0.0.0/0
$BWorknets — red de trabajo, en nuestro ejemplo aquí será 168
$CWorknets — red de trabajo, en nuestro ejemplo aquí será 0
$BVoipNets — red VOIP en nuestro ejemplo aquí 22
$CVoipNets — red VOIP en nuestro ejemplo aquí 4
$CClientss — Red para clientes, acceso solo a internet, en nuestro caso aquí 0
$BVPNWORKs — red VPN para grandes sucursales, en nuestro ejemplo 20
$CVPNWORKs — red VPN para grandes sucursales, en nuestro ejemplo 255
$BVPNCLIENTS — red VPN para pequeñas sucursales, es decir, 19
$CVPNCLIENTS — red VPN para pequeñas sucursales, es decir, 255
$NAMEROUTER — nombre del enrutador
$ServerCertificate — nombre del certificado, que debe importarse previamente
$infile — Especificar la ruta al archivo desde el cual leeremos la configuración, por ejemplo D:config.txt (mejor una ruta en inglés sin comillas y espacios)
$outfile — especificar la ruta donde guardar, por ejemplo D:MT-test.txt
He cambiado intencionadamente las direcciones en los ejemplos por razones obvias.
Me salté el punto sobre la detección de ataques y comportamientos anormales, esto merece un artículo aparte. Pero vale la pena señalar que en esta categoría se pueden usar los valores de monitoreo de Zabbix + los datos procesados de curl con elasticsearch.
En qué momentos es necesario prestar atención:
- Plan de redes. Es mejor elaborarlo de inmediato en un formato legible. Excel es más que suficiente. Desafortunadamente, a menudo veo que las redes se crean bajo el principio de 'Apareció una nueva sucursal, aquí tienes un /24'. Nadie investiga cuántos dispositivos se esperan en ese lugar y si habrá crecimiento futuro. Por ejemplo, se abrió una pequeña tienda, donde inicialmente está claro que no habrá más de 10 dispositivos, ¿por qué asignar un /24? En el caso de grandes sucursales, al contrario, asignan un /24, pero hay 500 dispositivos; se puede agregar más red, pero querría que todo estuviera bien pensado desde el principio.
- Reglas de filtración. Si el proyecto prevé que habrá separación de redes y segmentación máxima. Las mejores prácticas cambian con el tiempo. Antes se separaban las redes de PC y la red de impresoras, ahora es bastante normal no dividir estas redes. Se debe usar el sentido común y no crear múltiples subredes donde no son necesarias ni combinar todos los dispositivos en una sola red.
- Configuraciones 'doradas' en todos los enrutadores. Es decir, si te has decidido por un plan, es mejor prever todo de inmediato y tratar de hacer que todas las configuraciones sean idénticas, siendo solo diferentes la lista de direcciones y las direcciones IP. En caso de problemas, el tiempo de depuración será menor.
- Los aspectos organizativos son tan importantes como los técnicos. A menudo, los empleados perezosos siguen las recomendaciones mencionadas "manualmente", sin utilizar configuraciones y scripts predefinidos, lo que al final genera problemas innecesarios.
Sobre el enrutamiento dinámico. Se utilizó OSPF con división en áreas. Pero esto es un banco de pruebas, en condiciones reales es más interesante configurar estas cosas.
Espero que nadie se haya molestado por no haber publicado las configuraciones de los enrutadores. Creo que los enlaces son suficientes, y a partir de ahí todo depende de los requisitos. Y, por supuesto, es necesario realizar más pruebas.
Les deseo a todos en el nuevo año que hagan realidad sus proyectos. ¡Que el acceso esté concedido contigo!
Fuente: habr.com
