Bonjour à tous. Cet article s'adresse à ceux qui possèdent de nombreux dispositifs MikroTik et qui souhaitent maximiser l'unification, afin de ne pas avoir à se connecter à chaque appareil individuellement. Dans cet article, je vais décrire un projet qui, malheureusement, n'est pas allé jusqu'à l'implémentation à cause de facteurs humains. En résumé : plus de 200 routeurs, configuration rapide et formation du personnel, unification par régions, filtrage des réseaux et de certains hôtes, possibilité d'ajouter facilement des règles sur tous les dispositifs, journalisation et contrôle d'accès.
Ce qui est décrit ci-dessous ne prétend pas être un cas prêt à l'emploi, mais j'espère que cela vous sera utile lors de la planification de vos réseaux et de la minimisation des erreurs. Certains points et solutions peuvent vous sembler incorrects – si c'est le cas, n'hésitez pas à laisser un commentaire. La critique sera une contribution à notre expérience collective. Donc, cher lecteur, jetez un œil aux commentaires, peut-être que l'auteur a commis une erreur grossière – la communauté pourra aider.
Le nombre de routeurs est entre 200 et 300, répartis sur différentes villes avec des qualités de connexion Internet variées. Il est nécessaire de tout organiser de manière esthétique et de bien expliquer aux administrateurs locaux comment tout fonctionnera.
Alors, par où commence tout projet ? Bien sûr, par Cahier des charges.
- L'organisation du plan de réseau pour toutes les filiales en fonction des exigences du client, la segmentation des réseaux (de 3 à 20 réseaux dans les filiales en fonction du nombre de dispositifs).
- Configuration des dispositifs dans chaque filiale. Vérification de la vitesse de connexion réelle du fournisseur dans différentes conditions de travail.
- Mise en place de la sécurité des dispositifs, gestion via liste blanche, détection automatique des attaques avec ajout automatique à la liste noire pour une durée déterminée, minimisation de l'utilisation d'outils techniques utilisés pour intercepter l'accès et abandon des dispositifs de maintenance.
- Mise en place de connexions VPN sécurisées avec filtrage selon les réseaux conformément aux exigences du client. Minimum de 3 connexions VPN de chaque filiale vers le centre.
- Sur la base des points 1 et 2. Sélectionner les chemins optimaux pour établir des VPN résilients. La technologie de routage dynamique peut être choisie par l'exécutant si justifiée correctement.
- Organisation de la priorisation du trafic selon les protocoles, ports, hôtes et autres services spécifiques utilisés par le client. (VOIP, hôtes avec services importants)
- Organisation de la surveillance et de la journalisation des événements des routeurs pour permettre aux employés du support technique de réagir.
Comme nous le comprenons, dans certains cas, le cahier des charges est établi à partir des exigences. J'ai formulé ces exigences moi-même après avoir écouté les problèmes principaux. J'envisageais la possibilité que la réalisation de ces points puisse être effectuée par quelqu'un d'autre.
Quels outils seront utilisés pour remplir ces exigences :
- Stack ELK (après un certain temps, j'ai réalisé qu'au lieu de logstash, fluentd serait utilisé).
- Ansible. Pour faciliter l'administration et la séparation des accès, nous utiliserons AWX.
- GITLAB. Pas besoin d'explications ici. Où irions-nous sans contrôle de version pour nos configurations.
- PowerShell. Il y aura un petit script pour la génération initiale de la configuration.
- Wiki documentaire, pour rédiger la documentation et les guides. Dans ce cas, nous utiliserons habr.com.
- La surveillance sera effectuée via Zabbix. Un schéma de connexions y sera également dessiné pour une compréhension générale.
Aspects de la configuration EFK
Pour le premier point, je décrirai uniquement l'idéologie sur laquelle les index seront construits. Il y a beaucoup
d'excellents articles sur la configuration et la réception des journaux provenant de dispositifs sous Mikrotik.
Je vais m'arrêter sur certains points :
1. Selon le schéma, il faut réfléchir à la réception des journaux depuis différents endroits et sur différents ports. Pour cela, nous allons utiliser un agrégateur de journaux. Nous souhaitons également créer des graphiques universels pour tous les routeurs avec possibilité de séparation des accès. Nous construisons donc les index de la manière suivante :
Voici un extrait de configuration avec fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Ainsi, nous pouvons combiner les routeurs et segmenter selon le plan : mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Pourquoi compliquer autant ? Nous comprenons que nous aurons 200 dispositifs ou plus. Nous ne pouvons pas surveiller tout cela. À partir de la version 6.8 d'Elasticsearch, des paramètres de sécurité sont disponibles (sans achat de licence), ce qui nous permet de répartir les droits d'affichage entre les employés du support technique ou les administrateurs systèmes locaux.
Tableaux, graphiques – ici, il faut juste s'entendre : utiliser soit un modèle uniforme, soit chacun fait comme bon lui semble.
2. En ce qui concerne la journalisation. Si nous activons le log dans les règles du pare-feu, les noms doivent être sans espaces. Comme on peut le voir, en utilisant une configuration simple dans fluentd, nous pouvons filtrer les données et créer des tableaux de bord pratiques. Sur l'image ci-dessous - mon routeur domestique.
3. Concernant l'espace occupé et les logs. En moyenne, avec 1000 messages par heure, les logs occupent entre 2 et 3 Mo par jour, ce qui, convenons-en, n'est pas beaucoup. Version elasticsearch 7.5.
ANSIBLE.AWX
Heureusement, nous avons un module prêt pour routeros.
J'ai mentionné AWX, mais les commandes ci-dessous concernent uniquement ansible en tant que tel – je pense que pour ceux qui ont travaillé avec ansible, il n'y aura pas de problème à l'utiliser via l'interface graphique d'AWX.
Je l'admets honnêtement, auparavant, j'ai regardé d'autres guides qui utilisaient ssh, et chacun avait différents problèmes avec les temps de réponse et d'autres soucis. Je répète, cela n'est pas allé plus loin que l'expérimentation – considérez cette information comme un essai, sans aller au-delà du banc d'essai composé de 20 routeurs.
Nous devons utiliser un certificat ou un compte. À vous de décider, je suis pour les certificats. Un point délicat concernant les droits. J'accorde des droits d'écriture – il ne sera même pas possible de faire un 'reset config'.
Pour la génération, la copie du certificat et l'importation, il ne devrait pas y avoir de problèmes :
En bref, voici la liste des commandesSur votre PC
ssh-keygen -t RSA, répondez aux questions et enregistrez la clé.
Copiez sur mikrotik :
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Vous devez d'abord créer un compte et lui attribuer des droits.
Vérifions la connexion par certificat
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Écrivez 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
Et voici un exemple 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
Comme on peut le voir dans la configuration ci-dessus, la création de ses propres playbooks n'est pas une tâche compliquée. Il suffit de bien maîtriser le cli de mikrotik. Imaginons une situation où il faut supprimer une address list avec des données spécifiques sur tous les routeurs, alors :
Trouver et supprimer/ip firewal address-list remove [find where list=«gov.ru»]
Je n'ai pas inclus l'intégralité de la liste des pare-feu ici, car elle sera individuelle pour chaque projet. Mais une chose est certaine, utilisez uniquement la liste d'adresses.
Pour GITLAB, tout est clair. Je ne vais pas m'attarder sur ce point. Tout est organisé par tâches, modèles et gestionnaires.
Powershell
Il y aura 3 fichiers. Pourquoi PowerShell ? On peut choisir n'importe quel outil pour générer des configurations, selon ce que chacun préfère. Dans ce cas, tout le monde utilise Windows sur son PC, donc pourquoi faire sur bash quand PowerShell est plus pratique ? À chacun son choix.
Voici le script proprement dit (simple et clair) :[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
Je vous prie de m'excuser, je ne peux pas publier toutes les règles car cela ne serait pas très esthétique. Vous pouvez les établir vous-même en vous basant sur les meilleures pratiques.
Par exemple, voici une liste de liens qui m'ont guidé ::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — il faut savoir qu'en activant fasttrack, les règles de priorisation et de shaping du trafic ne fonctionneront pas – utile pour les appareils plus faibles.
Légende des variables :Les exemples suivants ont été pris :
192.168.0.0/24 réseau de travail
172.22.4.0/24 réseau VOIP
10.0.0.0/24 réseau pour clients sans accès au réseau local
192.168.255.0/24 réseau VPN pour grandes filiales
172.19.255.0/24 réseau VPN pour petites
L'adresse du réseau se compose de 4 chiffres décimaux, soit A.B.C.D, le principe de remplacement fonctionne de la même manière, si à l'exécution il demande B, alors il faut entrer pour le réseau 192.168.0.0/24 le numéro 0, et pour C = 0.
$EXTERNALIPADDRESS — adresse dédiée de l'opérateur.
$EXTERNALIPROUTE — route par défaut vers le réseau 0.0.0.0/0
$BWorknets — Réseau de travail, dans notre exemple ce sera 168
$CWorknets — Réseau de travail, dans notre exemple ce sera 0
$BVoipNets — un réseau VOIP, dans notre exemple ici 22
$CVoipNets — un réseau VOIP, dans notre exemple ici 4
$CClientss — réseau pour les clients – accès uniquement à Internet, dans notre cas ici 0
$BVPNWORKs — un réseau VPN pour de grandes filiales, dans notre exemple 20
$CVPNWORKs — un réseau VPN pour de grandes filiales, dans notre exemple 255
$BVPNCLIENTS — un réseau VPN pour de petites filiales, donc 19
$CVPNCLIENTS — un réseau VPN pour de petites filiales, donc 255
$NAMEROUTER — nom du routeur
$ServerCertificate — nom du certificat à importer au préalable
$infile — Indiquer le chemin du fichier à partir duquel nous allons lire la configuration, par exemple D:config.txt (préférez un chemin anglais sans guillemets ni espaces)
$outfile — indiquer le chemin où sauvegarder, par exemple D:MT-test.txt
J'ai intentionnellement modifié les adresses dans les exemples pour des raisons évidentes.
J'ai omis le point sur la détection des attaques et des comportements anormaux – cela mérite un article séparé. Mais il convient de mentionner que dans cette catégorie, on peut utiliser les valeurs de surveillance de Zabbix + les données traitées avec curl et elasticsearch.
Sur quels points il est nécessaire d'attirer l'attention :
- Plan des réseaux. Il est préférable de le rédiger dès le départ de manière lisible. Un simple fichier excel suffit. Malheureusement, je vois très souvent que les réseaux sont composés selon le principe « Un nouveau bureau est apparu, voici un /24 ». Personne ne s'informe sur le nombre d’appareils prévus à cet endroit et s'il y aura une expansion future. Par exemple, un petit magasin a ouvert, où il est clair dès le départ qu'il n'y aura pas plus de 10 appareils, pourquoi attribuer un /24 ? Pour les grandes filiales, au contraire, on attribue un /24, mais il y a 500 appareils — il est facile d’ajouter un réseau, mais il vaut mieux réfléchir à tout dès le début.
- Règles de filtrage. Si le projet prévoit une séparation des réseaux et une segmentation maximale. Les meilleures pratiques évoluent avec le temps. Auparavant, on séparait le réseau des PC et celui des imprimantes, maintenant, il est tout à fait acceptable de ne pas séparer ces réseaux. Il convient d'utiliser le bon sens et de ne pas multiplier les sous-réseaux là où ils ne sont pas nécessaires et de ne pas regrouper tous les appareils dans un seul réseau.
- Les réglages « dorés » sur tous les routeurs. C'est-à-dire, si vous avez décidé du plan. Il vaut mieux tout prévoir immédiatement et essayer de faire en sorte que tous les réglages soient identiques, seules les listes d'adresses et les adresses IP variant. En cas de problèmes, le temps de débogage sera réduit.
- Les aspects organisationnels sont tout aussi importants que les considérations techniques. Souvent, des employés peu motivés appliquent les recommandations données « manuellement », sans utiliser les configurations et scripts prêts à l'emploi, ce qui finit par causer des problèmes inutiles.
Concernant le routage dynamique. OSPF a été utilisé avec une division en zones. Mais après tout, il s'agit d'un banc d'essai, il est beaucoup plus intéressant de configurer ces choses en conditions réelles.
J'espère que personne n'est déçu de ne pas avoir publié les configurations des routeurs. Je pense que des liens suffisent, et après cela, tout dépend des exigences. Bien sûr, il est nécessaire de faire plus de tests.
Je souhaite à tous de réaliser vos projets dans cette nouvelle année. Que l'accès vous soit accordé !!!
Source : habr.com
