Моят незавършен проект. Мрежа от 200 рутера MikroTik

Здравейте всички. Тази статия е предназначена за тези, които имат много Mikrotik устройства във флота си и искат да направят максимална унификация, за да не се свързват към всяко устройство поотделно. В тази статия ще опиша проект, който, за съжаление, не достигна до бойни условия поради човешки фактор. Накратко: повече от 200 рутера, бърза настройка и обучение на персонала, унификация по региони, филтриране на мрежи и конкретни хостове, възможност за лесно добавяне на правила към всички устройства, логване и контрол на достъпа.

Описаното по-долу не претендира за готов случай, но се надявам да ви бъде полезно при планирането на вашите мрежи и минимизиране на грешките. Може би някои точки и решения може да не ви изглеждат напълно правилни - ако е така, напишете в коментарите. Критиката в този случай ще бъде опит за общата хазна. Затова, читателю, погледнете коментарите, може би авторът е направил сериозна грешка - общността ще помогне.

Броят на рутерите е 200-300, разпръснати в различни градове с различно качество на интернет връзките. Необходимо е да направите всичко красиво и ясно да обясните на местните администратори как ще работи всичко.

И така, откъде започва всеки проект? Разбира се, с TK.

1. Организиране на мрежов план за всички клонове според изискванията на клиента, сегментиране на мрежата (от 3 до 20 мрежи в клонове в зависимост от броя на устройствата).
2. Настройка на устройства във всеки клон. Проверка на реалната пропускателна способност на доставчика при различни работни условия.
3. Организиране на защита на устройството, управление на бели списъци, автоматично откриване на атаки с автоматично поставяне в черен списък за определен период от време, минимизиране на използването на различни технически средства, използвани за прихващане на контролен достъп и отказ на услуга.
4. Организиране на защитени VPN връзки с мрежово филтриране според изискванията на клиента. Минимум 3 VPN връзки от всеки клон към центъра.
5. Въз основа на точки 1, 2. Изберете оптималните начини за изграждане на устойчиви на грешки VPN. Ако е обосновано правилно, технологията за динамично трасиране може да бъде избрана от изпълнителя.
6. Организация на приоритизиране на трафика по протоколи, портове, хостове и други специфични услуги, използвани от клиента. (VOIP, хостове с важни услуги)
7. Организиране на мониторинг и регистриране на събития на рутера за реакция на персонала за техническа поддръжка.

Както разбираме, в редица случаи техническите спецификации се изготвят въз основа на изискванията. Аз сам формулирах тези изисквания, след като изслушах основните проблеми. Той допусна възможност някой друг да се погрижи за тези точки.

Какви инструменти ще се използват за изпълнение на тези изисквания:

1. ELK stack (след известно време стана ясно, че fluentd ще се използва вместо logstash).
2. Анзибъл. За по-лесно администриране и споделяне на достъп ще използваме AWX.
3. GITLAB. Тук няма нужда да обяснявам. Къде бихме били без контрол на версиите на нашите конфигурации?
4. PowerShell. Ще има прост скрипт за първоначалното генериране на конфигурацията.
5. Doku wiki, за писане на документация и ръководства. В този случай използваме habr.com.
6. Мониторингът ще се извършва чрез zabbix. Там ще бъде начертана и схема на свързване за общо разбиране.

Точки за настройка на EFK

Що се отнася до първата точка, ще опиша само идеологията, по която ще се изграждат индексите. Има много
отлични статии за настройка и получаване на регистрационни файлове от устройства, работещи с mikrotik.

Ще се спра на някои точки:

1. Според диаграмата си струва да обмислите получаването на регистрационни файлове от различни места и на различни портове. За целта ще използваме лог агрегатор. Също така искаме да направим универсална графика за всички рутери с възможност за споделяне на достъп. След това изграждаме индексите, както следва:

ето част от конфигурацията с fluentd тип elasticsearch
logstash_format вярно
име_индекс mikrotiklogs.север
logstash_prefix mikrotiklogs.north
flush_interval 10s
Силите еластично търсене: 9200
порт 9200

По този начин можем да комбинираме рутери и да сегментираме според плана - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Защо да го правим толкова сложно? Разбираме, че ще имаме 200 или повече устройства. Не можете да следите всичко. С версия 6.8 на elasticsearch настройките за сигурност са достъпни за нас (без закупуване на лиценз), като по този начин можем да разпределим правата за гледане между служители на техническата поддръжка или локални системни администратори.
Таблици, графики - тук просто трябва да се съгласите - или използвайте едни и същи, или всеки прави това, което му е удобно.

2. Чрез сеч. Ако активираме влизане в правилата на защитната стена, тогава правим имената без интервали. Може да се види, че с помощта на проста конфигурация във fluentd можем да филтрираме данни и да направим удобни панели. На снимката по-долу е моят домашен рутер.

3. По заето място и трупи. Средно при 1000 съобщения на час логовете заемат 2-3 MB на ден, което, както виждате, не е толкова много. Elasticsearch версия 7.5.

ANSIBLE.AWX

За наше щастие имаме готов модул за рутерите
Споменах за AWX, но командите по-долу са само за ansible в неговата чиста форма - мисля, че за тези, които са работили с ansible, няма да има проблеми с използването на awx през gui.

Честно казано, преди това разгледах други ръководства, където използваха ssh, и всички те имаха различни проблеми с времето за реакция и куп други проблеми. Повтарям, не се стигна до битка , приемете тази информация като експеримент, който не е стигнал по-далеч от стойка от 20 рутера.

Трябва да използваме сертификат или акаунт. Вие решавате, аз съм за сертификатите. Някаква тънка точка относно правата. Давам права за запис - поне „нулиране на конфигурацията“ няма да работи.

Не би трябвало да има проблеми с генерирането, копирането и импортирането на сертификата:

Кратък списък с командиНа вашия компютър
ssh-keygen -t RSA, отговори на въпроси, запиши ключа.
Копиране в mikrotik:
потребителски ssh-ключове import public-key-file=id_mtx.pub user=ansible
Първо трябва да създадете акаунт и да му зададете права.
Проверка на връзката с помощта на сертификата
ssh -p 49475 -i /ключове/mtx [имейл защитен]

Регистрирайте 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

Е, примерна книга за игра: - име: add_work_sites
хостове: testmt
сериен: 1
връзка: network_cli
дистанционен_потребител: mikrotik.west
gather_facts: да
задачи:
- име: добавете Work_sites
routeros_command:
команди:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip списък с адреси на защитната стена add address=habr.com list=work_sites comment=for_habr

Както можете да видите от горната конфигурация, създаването на ваши собствени книги за игри не е трудно. Достатъчно е да овладеете добре cli mikrotik. Нека си представим ситуация, в която трябва да премахнете списъка с адреси с определени данни на всички рутери, след което:

Намерете и премахнете/ip firewall адрес-списък премахване [find where list="gov.ru"]

Умишлено не включих целия списък на защитната стена тук, защото... ще бъде индивидуално за всеки проект. Но едно нещо мога да кажа със сигурност, използвайте само списъка с адреси.

Според GITLAB всичко е ясно. Няма да се спирам на тази точка. Всичко е красиво за индивидуални задачи, шаблони, манипулатори.

PowerShell

Тук ще има 3 файла. Защо powershell? Можете да изберете всеки инструмент за генериране на конфигурации, който ви е по-удобен. В този случай всеки има Windows на компютъра си, така че защо да го правите в bash, когато powershell е по-удобно. Кое е по-удобно?

Самият скрипт (прост и разбираем):[cmdletBinding()] Param(
[Параметър(Mandatory=$true)] [низ]$EXTERNALIPADDDRESS,
[Параметър(Mandatory=$true)] [низ]$EXTERNALIPROUTE,
[Параметър(Mandatory=$true)] [низ]$BWorknets,
[Параметър(Mandatory=$true)] [низ]$CWorknets,
[Параметър(Mandatory=$true)] [низ]$BVoipNets,
[Параметър(Mandatory=$true)] [низ]$CVoipNets,
[Параметър(Mandatory=$true)] [низ]$CClientss,
[Параметър(Mandatory=$true)] [низ]$BVPNWORKs,
[Параметър(Mandatory=$true)] [низ]$CVPNWORKs,
[Параметър(Mandatory=$true)] [низ]$BVPNCLIENTSs,
[Параметър(Mandatory=$true)] [низ]$cVPNCLIENTSs,
[Параметър(Mandatory=$true)] [низ]$NAMEROUTER,
[Параметър(Mandatory=$true)] [низ]$ServerCertificates,
[Параметър(Mandatory=$true)] [низ]$infile,
[Параметър(Mandatory=$true)] [низ]$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

Моля да ме извините, не мога да публикувам всички правила, защото... няма да е много красиво. Можете сами да съставите правилата, като се ръководите от най-добрите практики.

Например, ето списък с връзки, които последвах:wiki.mikrotik.com/wiki/Manual:Защита на_вашия_рутер
wiki.mikrotik.com/wiki/Manual:IP/Защитна стена/Филтър
wiki.mikrotik.com/wiki/Manual:OSPF-примери
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual: Winbox
wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack - тук трябва да знаете, че когато е активиран fasttrack, правилата за приоритизиране на трафика и оформяне няма да работят - полезно за слаби устройства.

Символи за променливи:Като пример са взети следните мрежи:
192.168.0.0/24 работеща мрежа
172.22.4.0/24 VOIP мрежа
10.0.0.0/24 мрежа за клиенти без достъп до локалната мрежа
192.168.255.0/24 VPN мрежа за големи клонове
172.19.255.0/24 VPN мрежа за малки

Мрежовият адрес се състои от 4 десетични числа, съответно ABCD, замяната работи на същия принцип, ако при стартиране иска B, това означава, че трябва да въведете числото 192.168.0.0 за мрежата 24/0, а за C = 0.
$EXTERNALIPADDDRESS - специален адрес от доставчика.
$EXTERNALIPROUTE - маршрут по подразбиране към мрежа 0.0.0.0/0
$BWorknets - Работна мрежа, в нашия пример ще има 168
$CWorknets - Работеща мрежа, в нашия пример това ще бъде 0
$BVoipNets - VOIP мрежа в нашия пример тук 22
$CVoipNets - VOIP мрежа в нашия пример тук 4
$CClientss - Мрежа за клиенти - само достъп до интернет, в нашия случай тук 0
$BVPNWORKs - VPN мрежа за големи клонове, в нашия пример 20
$CVPNWORKs - VPN мрежа за големи клонове, в нашия пример 255
$BVPNCLIENTS - VPN мрежа за малки клонове, което означава 19
$CVPNCLIENTS - VPN мрежа за малки клонове, което означава 255
$NAMEROUTER - име на рутер
$ServerCertificate - името на сертификата, който сте импортирали преди това
$infile — Посочете пътя до файла, от който ще прочетем конфигурацията, например D:config.txt (за предпочитане английският път без кавички и интервали)
$outfile — посочете пътя, където да го запишете, например D:MT-test.txt

Умишлено промених адресите в примерите по очевидни причини.

Пропуснах темата за откриването на атаки и аномално поведение - това заслужава отделна статия. Но си струва да се отбележи, че в тази категория можете да използвате стойности на данни за наблюдение от Zabbix + обработени данни за къдрици от elasticsearch.

На какви точки трябва да обърнете внимание:

1. Мрежов план. По-добре е да го съставите веднага в четлива форма. Excel ще е достатъчен. За съжаление много често виждам, че мрежите са изградени на принципа „Появи се нов клон, ето /24 за вас.“ Никой не смята колко устройства се очакват на дадено място или дали ще има по-нататъшен растеж. Например, отвори се малък магазин, в който първоначално беше ясно, че устройството няма да бъде повече от 10, защо да разпределяте /24? За големите клонове, напротив, те разпределят /24 и има 500 устройства - можете просто да добавите мрежа, но искате да обмислите всичко наведнъж.
2. Правила за филтриране. Ако проектът предполага, че ще има разделяне на мрежите и максимална сегментация. Най-добрите практики се променят с времето. Преди компютърната мрежа и принтерната мрежа бяха разделени, но сега е съвсем нормално тези мрежи да не се разделят. Струва си да използвате здравия разум и да не създавате много подмрежи, където не са необходими, и да не комбинирате всички устройства в една мрежа.
3. „Златни“ настройки на всички рутери. Тези. ако сте решили план. Струва си да предвидите всичко веднага и да се опитате да се уверите, че всички настройки са идентични - само списъкът с адреси и IP адресите са различни. Ако възникнат проблеми, времето за отстраняване на грешки ще бъде по-малко.
4. Организационните въпроси са не по-малко важни от техническите. Често мързеливите служители изпълняват тези препоръки „ръчно“, без да използват готови конфигурации и скриптове, което в крайна сметка води до проблеми от нищото.

Чрез динамично маршрутизиране. Използван е OSPF с разделяне на зони. Но това е тестов стенд, по-интересно е да се настройват такива неща в бойни условия.

Надявам се никой да не се сърди, че не съм публикувал конфигурациите на рутера. Мисля, че линковете ще са достатъчни, а след това всичко зависи от изискванията. И разбира се тестове, необходими са още тестове.

Пожелавам на всички да реализират своите проекти през новата година. Нека предоставеният достъп е с вас!!!

Източник: www.habr.com