Ahoj všichni. Tento článek je určen pro ty, kteří mají ve svém portfoliu mnoho zařízení MikroTik a chtějí dosáhnout maximální unifikace, aby nemuseli připojovat každé zařízení zvlášť. V tomto článku popíšu projekt, který, bohužel, nedosáhl provozních podmínek kvůli lidským faktorům. Stručně: více než 200 routerů, rychlé nastavení a školení personálu, unifikace podle regionů, filtrování sítí a určitých hostitelů, možnost snadného přidávání pravidel na všechna zařízení, logování a kontrola přístupu.
To, co je popsáno níže, si nečiní nárok na hotový případ, ale doufám, že vám to pomůže při plánování vašich sítí a minimalizaci chyb. Možná vám některé body a řešení přijdou nesprávné – pokud ano, napište do komentářů. Kritika v tomto případě bude zkušeností do společné pokladnice. Proto, čtenáři, podívejte se do komentářů, možná autor udělal hrubou chybu – komunita pomůže.
Počet routerů je 200-300, rozptýlených po různých městech s různou kvalitou internetového připojení. Je třeba vše udělat pěkně a jasně vysvětlit místním administrátorům, jak to bude fungovat.
A tedy, jak každé projekt začíná. Samozřejmě s Technické požadavky.
- Organizace plánu sítí ve všech pobočkách podle požadavků zákazníka, segmentace sítí (od 3 do 20 sítí v pobočkách v závislosti na počtu zařízení).
- Nastavení zařízení v každé pobočce. Kontrola skutečné propustnosti poskytovatele za různých pracovních podmínek.
- Organizace ochrany zařízení, správa pomocí bílého seznamu, automatické detekování útoků s automatickým přidáním na černou listinu na určité časové období, minimalizace použití různých technických prostředků používaných pro odposlech správy a odmítnutí údržby.
- Organizace zabezpečených VPN spojení s filtrováním podle sítí podle požadavků zákazníka. Minimálně 3 VPN spojení z každé pobočky do centra.
- Na základě bodů 1 a 2. Vybrat optimální cesty pro budování odolných VPN. Technologii dynamického směrování může zvolit vykonavatel s řádným odůvodněním.
- Organizace prioritizace provozu podle protokolů, portů, hostitelů a dalších specifických služeb, které zákazník používá. (VOIP, hostitelé s důležitými službami)
- Organizace monitorování a logování událostí routerů pro reakci zaměstnanců technické podpory.
Jak rozumíme, v řadě případů se zadání vypracovává na základě požadavků. Tyto požadavky jsem formuloval sám na základě vyslechnutí hlavních problémů. Připouštěl jsem možnost, že se plněním těchto bodů může zabývat někdo jiný.
Jaké nástroje budou použity pro splnění těchto požadavků:
- Stoh ELK (po nějaké době přišlo pochopení, že místo logstash bude použit fluentd).
- Ansible. Pro usnadnění správy a rozdělení přístupu budeme používat AWX.
- GITLAB. Tady není třeba vysvětlovat. Kam bychom sešli bez kontroly verzí našich konfigurací.
- PowerShell. Bude jednoduchý skript pro počáteční generaci konfigurace.
- Dokumentační wiki, pro psaní dokumentace a příruček. V tomto případě použijeme habr.com.
- Monitoring bude prováděn pomocí zabbixu. Tam bude také nakreslena schéma připojení pro celkové pochopení.
Moment nastavení EFK.
K prvnímu bodu popíšu pouze ideologii, podle které budou indexy budovány. Existuje mnoho
skvělých článků o nastavení a příjmu logů z zařízení spravovaných mikrotikem.
Zastavím se na některých aspektech:
1. Podle schématu je třeba promyslet příjem logů z různých míst a na různé porty. K tomu budeme používat agregátor logů. Také bychom chtěli vytvořit univerzální grafy pro všechny routery s možností rozdělení přístupu. Indexy tedy budujeme následujícím způsobem:
toto je kus konfigurace s fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Tímto způsobem můžeme spojit routery a segmentovat podle plánu - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Proč to tak komplikovat? Chápeme, že budeme mít 200 a více zařízení. Na všechno nedohlédneme. Od verze 6.8 elasticsearch máme k dispozici bezpečnostní nastavení (bez zakoupení licence), což nám umožňuje rozdělit práva na zobrazení mezi zaměstnance technické podpory nebo místní systémové administrátory.
Tabulky a grafy – zde je potřeba se prostě domluvit – buď použít jednotné, nebo ať si každý udělá, jak mu to bude vyhovovat.
2. Co se týče logování. Pokud v pravidlech firewallu zapneme log, měníme názvy na bez mezer. Je evidentní, že použitím jednoduchého konfigu ve fluentd můžeme filtrovat data a vytvářet přehledné panely. Na obrázku níže – můj domácí router.
3. Co se týče obsazení místa a logů. Průměrně, při 1000 zprávách za hodinu, logy zabírají 2-3 MB denně, což, uznejme, není tolik. Verze elasticsearch 7.5.
ANSIBLE.AWX
Naštěstí máme k dispozici hotový modul pro routeros.
Zmínil jsem AWX, ale níže uvedené příkazy jsou pouze o ansible v čisté podobě – myslím, že pro ty, kteří pracovali s ansible, nebudou mít problémy s používáním přes gui awx.
Musím se přiznat, že jsem předtím sledoval jiné návody, kde používali ssh, a všichni měli různé problémy s odezvou a spoustu dalších problémů. Opakuji, k boji nedošlo , považujte tuto informaci jako experiment, který se nedostal dál než k testu s 20 routery.
Je nutné použít certifikát nebo účet. Tady rozhodujete vy, já jsem pro certifikáty. Nějaký subtilní moment ohledně práv. Dávám práva na zapisování – alespoň „reset config“ udělat nepůjde.
Při generování, kopírování certifikátu a importu by neměly nastat problémy:
Krátký výpis příkazůNa vašem PC
ssh-keygen -t RSA, odpovídáme na otázky, uložíme klíč.
Kopírujeme na mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Nejdříve je třeba vytvořit účet a přiřadit mu práva.
Kontrolujeme připojení pomocí certifikátu
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Zapisujeme 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
A zde je příklad playbooku: - 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
Jak je vidět z výše uvedené konfigurace, sestavení vlastních playbooků není složité. Stačí se dobře naučit cli mikrotik. Představme si situaci, kdy je třeba na všech routerech odstranit address list s určitými daty, pak:
Najít a odstranit/ip firewal address-list remove [find where list=«gov.ru»]
Úmyslně jsem sem nezadal celý výpis firewallu, protože bude individuální pro každý projekt. Mohu však říci jedno: používejte pouze seznam adres.
Co se týče GITLABu, je to jasné. Nejsem si jistý, zda je potřeba se k tomu dále vyjadřovat. Vše je přehledně uspořádáno podle jednotlivých úkolů, šablon a handlerů.
Powershell
Zde budou 3 soubory. Proč powershell? Nástroj na generování konfigurací může být jakýkoliv, co je komu pohodlnější. V tomto případě mají všichni na PC Windows, takže proč používat bash, když je pohodlnější powershell. Každý má své preference.
Samotný skript (jednoduchý a srozumitelný):[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
Omlouvám se, nemohu zveřejnit všechna pravidla, protože by to nebylo úplně estetické. Pravidla si můžete vytvořit sami, podle osvědčených praktik.
Například zde je seznam odkazů, kterými jsem se řídil::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — je třeba mít na paměti, že při aktivaci fasttrack nebudou fungovat pravidla priorizace a shaping provozu – užitečné pro slabé zařízení.
Označení proměnných:Příklad se bere z následujících sítí:
192.168.0.0/24 pracovní síť
172.22.4.0/24 VOIP síť
10.0.0.0/24 síť pro klienty bez přístupu do lokální sítě
192.168.255.0/24 VPN síť pro velké pobočky
172.19.255.0/24 VPN síť pro malé
Adresa sítě se skládá ze 4 desítkových číslic, tedy A.B.C.D, podle stejného principu probíhá výměna, pokud při spuštění požaduje B, znamená to, že pro síť 192.168.0.0/24 je třeba zadat číslo 0, a pro C = 0.
$EXTERNALIPADDRESS — dedikovaná adresa od poskytovatele.
$EXTERNALIPROUTE — výchozí směrování pro síť 0.0.0.0/0
$BWorknets — Pracovní síť, v našem příkladu zde bude 168
$CWorknets — Pracovní síť, v našem příkladu zde bude 0
$BVoipNets — VOIP síť, zde v našem příkladu 22
$CVoipNets — VOIP síť, zde v našem příkladu 4
$CClientss — Síť pro klienty – přístup pouze na internet, zde v našem případě 0
$BVPNWORKs — VPN síť pro velké pobočky, v našem příkladu 20
$CVPNWORKs — VPN síť pro velké pobočky, v našem příkladu 255
$BVPNCLIENTS — VPN síť pro malé pobočky, tedy 19
$CVPNCLIENTS — VPN síť pro malé pobočky, tedy 255
$NAMEROUTER — název routeru
$ServerCertificate — název certifikátu, který předem importujete
$infile — Zadejte cestu k souboru, ze kterého budeme číst konfiguraci, například D:config.txt (lépe anglická cesta bez uvozovek a mezer)
$outfile — zadejte cestu, kde uložit, například D:MT-test.txt
Úmyslně jsem změnil adresy v příkladech z jasných důvodů.
Vynechal jsem bod o detekci útoků a anomálního chování – to si zaslouží samostatný článek. Ale stojí za zmínku, že v této kategorii lze využít hodnoty monitorovacích dat ze Zabbixu + zpracovaná data curl z elasticsearch.
Na jaké momenty je třeba se zaměřit:
- Plán sítí. Je lepší jej hned zpracovat v čitelné podobě. Bohatě postačí excel. Bohužel velmi často vidím, že sítě se plánují podle principu „Objevil se nový pobočka, zde máte /24“. Nikdo nezjistí, kolik zařízení se předpokládá na daném místě a zda bude další růst. Například se otevřel malý obchod, kde už je jasné, že zařízení bude maximálně 10, proč vyčleňovat /24? U velkých poboček naopak vyčleňují /24 a zařízení je 500 — síť je možné pouze přidat, ale je dobré vše promyslet hned.
- Pravidla filtrování. Pokud projekt předpokládá, že dojde k rozdělení sítí a maximální segmentaci. Best Practice se v průběhu času mění. Dříve se síť PC a síť tiskáren oddělovaly, nyní je zcela v pořádku tyto sítě nesdělovat. Je třeba použít zdravý rozum a neplodit množství podsítí tam, kde nejsou potřeba, a nespojovat všechna zařízení do jedné sítě.
- „Zlatá“ nastavení na všech routerech. Tedy pokud jste se rozhodli pro plán. Je dobré vše hned předpokládat a snažit se zajistit, aby všechna nastavení byla identická — měly pouze různé adresní seznamy a ip adresy. V případě problémů bude čas na ladění kratší.
- Organizační aspekty jsou stejně důležité jako technické. Často línější zaměstnanci plní uvedená doporučení "ručně", aniž by používali připravené konfigurace a skripty, což nakonec vede k problémům na prázdném místě.
Co se týče dynamického směrování. Používal se OSPF se zónovým dělením. Ale to přece není produkční prostředí, v reálných podmínkách je nastavování těchto věcí zajímavější.
Doufám, že se nikdo nezlobil, že jsem nevložil konfigurace směrovačů. Myslím, že odkazy stačí, a dál to už závisí na požadavcích. A samozřejmě testy, potřebujeme více testů.
Přeji všem v novém roce realizaci svých projektů. Ať s vámi zůstane access granted!!!
Zdroj: habr.com
