Всім привіт. Ця стаття розрахована на тих, хто має в парку багато пристроїв мікротик, і хто хоче зробити максимальну уніфікацію, щоб не підключатися на кожен пристрій окремо. У цій статті я опишу проект, який, на жаль, не дійшов до бойових умов через людські чинники. Коротко: понад 200 маршрутизаторів, швидке налаштування та навчання персоналу, уніфікація по регіонах, фільтрація мереж та певних хостів, можливість легкого додавання правил на всі пристрої, логування та контроль доступу.
Те, що описано нижче, не претендує на готовий кейс, але сподіваюся нагоді вам при плануванні своїх мереж та мінімізації помилок. Можливо, деякі пункти та рішення вам здадуться не зовсім правильними – якщо так, пишіть у коментарі. Критика у разі буде досвідом у загальну скарбничку. Тому, читачу, заглянь у коментарі, можливо, автор припустився грубої помилки – спільнота допоможе.
Кількість маршрутизаторів 200-300, розкидані по різних містах з різною якістю інтернет-з'єднання. Необхідно зробити все красиво і доступно роз'яснити локальним адмінам, як усе працюватиме.
Отже, з чого починається будь-який проект. Звичайно ж, з ТЗ.
- Організація плану мереж по всіх філіях згідно з вимогами замовника, сегментація мереж (від 3 до 20 мереж у філіях залежно від кількості пристроїв).
- Налаштування пристроїв у кожній філії. Перевіряє реальну пропускну швидкість провайдера в різних умовах роботи.
- Організація захисту пристроїв, управління за білим списком, автодектування атак з автозанесенням до чорного списку на певний проміжок часу, мінімалізація використання різних технічних засобів, що використовуються для перехоплення доступу керування та відмови від обслуговування.
- Організація захищених vpn з'єднань із фільтрацією по мережах відповідно до вимог замовника. Мінімум 3 vpn з'єднання з кожної філії до центру.
- На основі пункту 1, 2. Вибрати оптимальні шляхи побудови відмовостійких vpn. Технологію динамічної маршрутизації при коректному обґрунтуванні може вибрати виконавець.
- Організація пріорітизації трафіку за протоколами, портами, хостами та іншими специфічними сервісами, які використовує замовник. (VOIP, хости з важливими сервісами)
- Організація моніторингу та логування подій маршрутизаторів для реагування співробітників технічної підтримки.
Як ми розуміємо, у ряді випадків ТЗ складається від вимог. Ці вимоги сформулював самостійно, вислухавши основні проблеми. Допускав можливість, що виконанням цих пунктів може зайнятися хтось інший.
Які інструменти будуть використовуватися для виконання цих вимог:
- Стек ELK (через деякий час, прийшло розуміння, що замість logstash буде використовуватися fluentd).
- Ansible. Для зручності адміністрування та поділу доступу будемо використовувати AWX.
- GITLAB. Тут не треба пояснювати. Куди без контролю версій конфігів.
- PowerShell. Буде просте скрипт для початкової генерації конфіга.
- Доку вікі, для написання документації та посібників. У даному випадку використовуємо habr.com.
- Моніторинг буде здійснюватись через zabbix. Там же буде намальовано схему підключень для загального розуміння.
Моменти налаштування EFK
За першим пунктом опишу лише ідеологію, за якою будуватимуться індекси. Є багато
прекрасних статей з налаштування та прийому логів із пристроїв під керуванням mikrotik.
Зупинюся на деяких моментах:
1. Згідно зі схемою, варто продумати прийом логів з різних місць та по різних портах. Для цього ми використовуватимемо агрегатор логів. А також хочеться зробити універсальні графіки для всіх маршрутизаторів з можливістю поділу доступу. Тоді індекси будуємо так:
tвось шматок конфігу з fluentd тип elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
хостів : 9200
порт 9200
Таким чином ми можемо об'єднати роутери і сегментувати згідно з планом- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Для чого так ускладнювати? Ми розуміємо, що ми матимемо 200 і більше пристроїв. За всім не встежити. З 6.8 версії elasticsearch нам доступні налаштування безпеки (без покупки ліцензії), тим самим, ми можемо розподілити права на перегляд між співробітниками технічної підтримки або локальними системними адміністраторами.
Таблиці, графіки - тут вже треба просто домовиться - або використовувати однакові, або кожен робить так, як йому буде зручно.
2. З логування. Якщо правила firewall включаємо log, то імена робимо без пробілів. Видно, що, використовуючи простий конфіг у fluentd, ми можемо фільтрувати дані та робити зручні панелі. На малюнку нижче мій домашній роутер.
3. За місцем і логами. У середньому, при 1000 повідомлень на годину, логи займають по 2-3 мб на добу, що, погодьтеся, не так багато. Версія еластичногодослідження 7.5.
ANSIBLE.AWX
На наше щастя у нас є, готовий модуль для routeros
Я вказав про AWX, але команди нижче тільки про ansible у чистому вигляді – думаю, для тих, хто працював з ansible, не виникне проблем із використанням через gui awx.
Зізнаюся чесно, до цього дивився інші гайди, де використовували ssh, і всі мали різні проблеми з часом відповіді і ще купу інших проблем. Повторюся, до бою не дійшло, сприймайте цю інформацію як експеримент, що не дійшов далі стенду з 20 роутерів.
Нам необхідно використовувати сертифікат чи облік. Тут вирішувати вам я за сертифікати. Деякий тонкий момент із прав. Даю права на write - хоча "reset config" зробити не вийде.
За генерацією, копіюванням сертифіката та імпорту не повинно виникнути проблем:
Коротко лістинг командНа вашому ПК
ssh-keygen -t RSA, відповідаємо на запитання, зберігаємо ключ.
Копіюємо на mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Попередньо треба створити облік та виділити їй права.
Перевіряємо підключення за сертифікатом
ssh -p 49475 -i /keys/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
Ну і приклад playbook: - name: add_work_sites
hosts: testmt
номер: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
завдання:
- name: add Work_sites
routeros_command:
команди:
- /ip firewall 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
Як видно з наведеної вище конфігурації, складання своїх playbook нескладна справа. Досить добре освоїти cli mikrotik. Уявимо ситуацію, коли на всіх роутерах треба прибрати address list з певними даними, тоді:
Знайти та видалити/ip firewal address-list remove [find where list=«gov.ru»]
Я не вставив сюди весь листинг файрвола т.к. він буде індивідуальним для кожного проекту. Але одне можу сказати точно, використовуйте лише address list.
По GITLAB все ясно. Не зупинятимуся на цьому моменті. Все красиво по окремих tasks, templates, handlers.
Powershell
Тут будуть 3 файлики. Чому PowerShell? Інструмент для генерації конфігів можна вибирати будь-кому, кому що зручніше. В даному випадку у всіх на пк стоїть windows, тому навіщо робити на bash, коли зручніше powershell. Кому що зручніше.
Безпосередньо сам скрипт (простий та зрозумілий):[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
Прошу вибачити мені, не можу викласти всі правила т.к. це буде зовсім красиво. Правила можете скласти самі, керуючись найкращими практиками.
Наприклад, ось список посилань за якими керувався я::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
: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.
$EXTERNALIPADDRESS — виділена адреса від провайдера.
$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 + відпрацьовані дані curl з elasticsearch.
На яких моментах необхідно звернути увагу:
- План мереж. Краще скласти відразу в читаному вигляді. Цілком вистачить excel. На жаль, дуже часто бачу, що мережі складаються за принципом «З'явилася нова філія, ось вам /24». Ніхто не з'ясовує, скільки передбачається пристроїв у цьому місці і чи буде подальше зростання. Наприклад, відкрився невеликий магазин, в якому спочатку зрозуміло, що пристрій буде не більше ніж 10, навіщо виділяти /24? За великими філіями – навпаки, виділяють /24, а пристроїв стає 500 – просто додати мережу можна, але хочеться все продумати одразу.
- Правила фільтрації Якщо за проектом передбачається, що буде розподіл мереж та максимальна сегментація. Best Practice поступово змінюються. Раніше ділили мережу ПК та мережу принтерів, зараз цілком нормально не ділити ці мережі. Варто використовувати здоровий глузд і не плодити безліч підмереж там, де вони не потрібні і не об'єднувати в одну мережу всі пристрої.
- "Золоті" налаштування на всіх роутерах. Тобто. якщо ви визначилися із планом. Варто відразу все передбачити і постаратися зробити так, щоб усі налаштування були ідентичними - були лише різні address list та ip адреси. У разі проблем, що виникають, час на налагодження буде менше.
- Організаційні моменти не менш важливі, ніж технічні. Часто ліниві співробітники виконують зазначені рекомендації «вручну», не використовуючи готові конфігурації та скрипти, що призводить до проблем на порожньому місці.
За динамічною маршрутизацією. Використовувався OSPF із зональним розподілом. Але це тестовий стенд, в бойових умовах такі речі налаштовувати цікавіше.
Сподіваюся, ніхто не засмутився, що я не виклав конфігурації маршрутизаторів. Думаю, що цілком вистачить посилань, а далі все залежить від вимог. І звичайно, тести, необхідно більше тестів.
Бажаю всім у новому році реалізувати свої проекти. Хай прибуде з вами access granted!
Джерело: habr.com