Olá a todos. Este artigo é destinado àqueles que possuem muitos dispositivos MikroTik e que desejam maximizar a padronização, evitando a conexão a cada dispositivo individualmente. Neste artigo, descreverei um projeto que, infelizmente, não avançou para condições práticas devido a fatores humanos. Em resumo: mais de 200 roteadores, configuração rápida e treinamento da equipe, padronização por regiões, filtragem de redes e hosts específicos, possibilidade de adição fácil de regras a todos os dispositivos, registro e controle de acesso.
O que está descrito abaixo não se pretende um caso pronto, mas espero que possa ser útil na planificação das suas redes e na minimização de erros. Pode ser que alguns pontos e soluções não lhe pareçam adequados – se for o caso, deixe seu comentário. Críticas, neste caso, serão experiências para a coletânea geral. Portanto, leitor, dá uma olhada nos comentários, talvez o autor tenha cometido um erro grave – a comunidade ajudará.
O número de roteadores varia de 200 a 300, espalhados por diferentes cidades com diferentes qualidades de conexão à internet. É necessário tornar tudo bonito e esclarecer de forma acessível para os administradores locais como tudo funcionará.
Então, de onde começa qualquer projeto. Claro, com Especificações.
- Organização do plano de redes para todas as filiais de acordo com as exigências do cliente, segmentação das redes (de 3 a 20 redes nas filiais, dependendo do número de dispositivos).
- Configuração dos dispositivos em cada filial. Verificação da largura de banda real do provedor em diferentes condições de operação.
- Organização da proteção dos dispositivos, gestão por lista branca, autodetecção de ataques com inclusão automática na lista negra por um determinado período, minimização do uso de diversos meios técnicos utilizados para interceptação de controle e desistência de manutenção.
- Organização de conexões VPN seguras com filtragem de redes conforme as exigências do cliente. Mínimo de 3 conexões VPN de cada filial até o centro.
- Com base nos pontos 1 e 2. Escolher os caminhos ideais para a construção de VPNs resilientes. A tecnologia de roteamento dinâmico pode ser escolhida pelo executor com a justificativa adequada.
- Organização da priorização do tráfego por protocolos, portas, hosts e outros serviços específicos utilizados pelo cliente. (VOIP, hosts com serviços importantes)
- Organização do monitoramento e registro de eventos de roteadores para a resposta dos funcionários do suporte técnico.
Como entendemos, em alguns casos o projeto é baseado nas exigências. Essas exigências eu as formulei sozinho, ouvindo os principais problemas. Considerei a possibilidade de que a execução desses pontos pudesse ser feita por outra pessoa.
Quais ferramentas serão utilizadas para atender a essas exigências:
- Stack ELK (depois de algum tempo, ficou claro que em vez de logstash seria utilizado o fluentd).
- Ansible. Para facilitar a administração e a divisão de acesso, usaremos AWX.
- GITLAB. Aqui não precisa de mais explicações. Para que nosso controle de versões dos configs.
- PowerShell. Haverá um script simples para a geração inicial do config.
- Wiki do Doku, para escrever documentação e manuais. Neste caso, usaremos habr.com.
- O monitoramento será feito através do zabbix. Também será desenhado um esquema de conexões para uma compreensão geral.
Momentos da configuração do EFK
No primeiro ponto, descreverei apenas a ideologia sobre a qual os índices serão construídos. Há muitos
artigos excelentes sobre a configuração e a recepção de logs de dispositivos sob controle do mikrotik.
Focarei em alguns pontos:
1. De acordo com o esquema, é preciso pensar na recepção de logs de diferentes locais e por diferentes portas. Para isso, usaremos um agregador de logs. Também queremos criar gráficos universais para todos os roteadores com a possibilidade de divisão de acesso. Assim, os índices serão construídos da seguinte forma:
aqui está um trecho do config com fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Dessa forma, podemos consolidar os roteadores e segmentar de acordo com o plano - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Por que complicar assim? Entendemos que teremos 200 ou mais dispositivos. Não podemos cobrar tudo. Com a versão 6.8 do elasticsearch, temos as configurações de segurança disponíveis (sem a compra de licença), assim, podemos distribuir os direitos de visualização entre os colaboradores do suporte técnico ou administradores de sistemas locais.
Tabelas e gráficos - aqui é preciso simplesmente entrar em acordo - ou usamos um formato uniforme, ou cada um faz da maneira mais conveniente para si.
2. Sobre o log. Se ativarmos o log nas regras do firewall, os nomes devem ser sem espaços. É evidente que, utilizando uma configuração simples no fluentd, podemos filtrar dados e criar painéis convenientes. Na imagem abaixo, está meu roteador doméstico.
3. Sobre o espaço ocupado e logs. Em média, com 1000 mensagens por hora, os logs ocupam de 2 a 3 MB por dia, o que, convenhamos, não é muito. Versão do elasticsearch 7.5.
ANSIBLE.AWX
Felizmente, temos um módulo pronto para routeros.
Mencionei sobre o AWX, mas os comandos abaixo são apenas sobre o ansible puro - acho que para aqueles que trabalharam com ansible, não haverá problemas em usá-lo através da gui awx.
Confesso honestamente que antes assisti a outros guias que usavam ssh e todos tinham problemas diferentes com o tempo de resposta e uma série de outros problemas. Reitero, antes que a batalha chegasse :) considere essa informação como um experimento que não avançou além de um banco de testes com 20 roteadores.
Precisamos usar um certificado ou uma conta. A decisão é sua, eu sou a favor dos certificados. Um pequeno detalhe sobre as permissões. Dou permissões para escrita - nem mesmo o 'reset config' conseguiremos fazer.
Sobre a geração, cópia de certificado e importação, não deve haver problemas:
Resumidamente, a lista de comandosNo seu PC
ssh-keygen -t RSA, respondemos às perguntas, salvamos a chave.
Copiamos para o mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Primeiro, é necessário criar uma conta e atribuir permissões a ela.
Verificamos a conexão pelo certificado
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Editamos 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
E aqui um exemplo 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 pode ser visto na configuração acima, criar seus próprios playbooks não é uma tarefa difícil. Basta dominar bem a cli do mikrotik. Vamos imaginar uma situação em que em todos os roteadores precisamos remover a address list com determinados dados, então:
Encontrar e remover/ip firewal address-list remove [find where list=«gov.ru»]
Eu não coloquei aqui toda a lista de firewall intencionalmente, pois ela será individual para cada projeto. Mas posso afirmar com certeza, use apenas a lista de endereços.
Quanto ao GITLAB, tudo está claro. Não vou me deter nesse ponto. Tudo está bem organizado em tarefas, templates e manipuladores separados.
Powershell
Aqui estarão três arquivos. Por que PowerShell? A ferramenta para gerar configurações pode ser qualquer uma, dependendo da preferência de cada um. No caso, todos têm Windows em seus PCs, então por que fazer em bash, quando PowerShell é mais conveniente? Cada um com seu conforto.
O próprio script (simples e claro):[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
Peço desculpas, não posso publicar todas as regras, pois isso não ficaria muito bonito. Você pode formular as regras por conta própria, seguindo as melhores práticas.
Por exemplo, aqui está uma lista de links que usei como referência::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — aqui é preciso saber que ao ativar o fasttrack, as regras de priorização e modelagem de tráfego não funcionarão – útil para dispositivos fracos.
Condições para as variáveis:Tomaremos as seguintes redes como exemplo:
192.168.0.0/24 rede de trabalho
172.22.4.0/24 rede de VOIP
10.0.0.0/24 rede para clientes sem acesso à rede local
192.168.255.0/24 rede VPN para grandes filiais
172.19.255.0/24 rede VPN para pequenas filiais
O endereço de rede consiste em 4 números decimais, ou seja, A.B.C.D, da mesma forma que a substituição é feita, se durante a execução pedir B, significa que para a rede 192.168.0.0/24 deve-se inserir o número 0, e para C = 0.
$EXTERNALIPADDRESS — endereço atribuído pelo provedor.
$EXTERNALIPROUTE — rota padrão para a rede 0.0.0.0/0
$BWorknets — Rede de trabalho, neste exemplo será 168
$CWorknets — Rede de Trabalho, no nosso exemplo aqui será 0
$BVoipNets — Rede VOIP no nosso exemplo aqui 22
$CVoipNets — Rede VOIP no nosso exemplo aqui 4
$CClientss — Rede para clientes – acesso apenas à internet, no nosso caso aqui 0
$BVPNWORKs — Rede VPN para grandes filiais, no nosso exemplo 20
$CVPNWORKs — Rede VPN para grandes filiais, no nosso exemplo 255
$BVPNCLIENTS — Rede VPN para pequenas filiais, ou seja, 19
$CVPNCLIENTS — Rede VPN para pequenas filiais, ou seja, 255
$NAMEROUTER — nome do roteador
$ServerCertificate — nome do certificado que você importará previamente
$infile — Especificar o caminho do arquivo do qual leremos a configuração, por exemplo D:config.txt (de preferência um caminho em inglês sem aspas e espaços)
$outfile — especificar o caminho onde salvar, por exemplo D:MT-test.txt
Eu intencionalmente mudei os endereços nos exemplos por razões óbvias.
Pulei a seção sobre detecção de ataques e comportamento anômalo – isso merece um artigo separado. Mas vale mencionar que nesta categoria é possível usar os dados de monitoramento do Zabbix + dados processados do curl com elasticsearch.
Nos pontos a serem destacados:
- Plano de redes. Melhor elaborá-lo imediatamente em um formato legível. Um Excel é mais do que suficiente. Infelizmente, vejo com frequência que as redes são elaboradas com a lógica de "Apareceu uma nova filial, aqui está um /24". Ninguém verifica quantos dispositivos são esperados neste local ou se haverá crescimento futuro. Por exemplo, uma pequena loja foi inaugurada, na qual fica claro desde o início que não haverá mais de 10 dispositivos; por que alocar um /24? Para grandes filiais – ao contrário, é alocado um /24, mas os dispositivos se tornam 500 – basta adicionar a rede, mas é melhor planejar tudo desde o início.
- Regras de filtragem. Se o projeto prevê a divisão de redes e a segmentação máxima. As melhores práticas mudam com o tempo. Anteriormente, dividíamos a rede de PCs e a rede de impressoras; agora, é perfeitamente aceitável não dividir essas redes. Deve-se usar o bom senso e evitar a multiplicação de sub-redes desnecessárias e não unir todos os dispositivos em uma única rede.
- Configurações "douradas" em todos os roteadores. Ou seja, se você definiu o plano, deve prever imediatamente tudo e tentar fazer com que todas as configurações sejam idênticas, diferenciando apenas a lista de endereços e os endereços IP. Em caso de problemas, o tempo para depuração será menor.
- Os aspectos organizacionais são tão importantes quanto os técnicos. Frequentemente, funcionários preguiçosos seguem as recomendações mencionadas "manualmente", sem usar configurações e scripts prontos, o que acaba resultando em problemas desnecessários.
Sobre roteamento dinâmico. Usou-se OSPF com divisão de áreas. Mas, afinal, este é um ambiente de teste, em condições reais, configurar essas coisas seria mais interessante.
Espero que ninguém tenha ficado desapontado por eu não ter compartilhado as configurações dos roteadores. Acho que referências são suficientes, e o resto depende dos requisitos. E, claro, testes, precisamos de mais testes.
Desejo a todos, neste novo ano, que realizem seus projetos. Que o acesso concedido esteja com você!!!
Fonte: habr.com
