Üdvözlet mindenkinek. Ez a cikk azoknak szól, akik sok MikroTik eszközzel rendelkeznek, és szeretnék maximalizálni a standardizálást, hogy ne kelljen minden egyes eszközhöz külön-külön csatlakozniuk. Ebben a cikkben bemutatom azt a projektet, amely sajnos nem jutott el a gyakorlati megvalósításig az emberi tényezők miatt. Röviden: több mint 200 router, gyors beállítás és a személyzet képzése, standardizálás régiók szerint, hálózatok és meghatározott hosztok szűrése, a szabályok könnyű hozzáadásának lehetősége minden eszközre, naplózás és hozzáférés-ellenőrzés.
A lent leírtak nem igényelnek kész megoldást, de remélhetőleg hasznosak lesznek a hálózataik tervezésében és a hibák minimalizálásában. Lehetséges, hogy egyes pontok vagy megoldások nem tűnnek helyesnek – ha így van, kérlek, írj a megjegyzések között. A kritika ebben az esetben tapasztalat a közös tudásba. Ezért, kedves olvasó, nézd meg a megjegyzéseket, lehet, hogy a szerző súlyos hibát követett el – a közösség segíteni fog.
A routerek száma 200-300, különböző városokban helyezkednek el, eltérő internetkapcsolati minőséggel. Mindennek szépen és érthetően kell megvalósulnia, hogy a helyi adminisztrátorok számára világosan elmagyarázzuk, hogyan fog működni.
Tehát, mivel kezdődik bármilyen projekt. Természetesen a Műszaki feladat.
- A hálózati terv megszervezése a fiókok között a megrendelő követelményei szerint, hálózatok szegmentálása (3 és 20 hálózat között a fiókokban a berendezések számától függően).
- Az eszközök beállítása minden fiókban. A valós átviteli sebesség ellenőrzése a szolgáltatóval különböző működési körülmények között.
- Az eszközök védelmének megszervezése, fehérlistás kezelés, támadások automatikus észlelése és automatikus felvétel a fekete listára meghatározott időtartamra, a különböző technikai eszközök minimalizálása, amelyek a vezérlési hozzáférés elfogására és karbantartás megszüntetésére használatosak.
- Biztosított VPN-kapcsolatok szervezése a hálózatok szűrésével a megrendelő követelményei szerint. Minimum 3 VPN-kapcsolat minden fiókból a központig.
- Az 1. és 2. pont alapján. Az optimális megoldások kiválasztása a hibatűrő VPN-ek kialakításához. A dinamikus útválasztási technológiát helyes indoklással választhatja meg a végrehajtó.
- A forgalom priorizálásának megszervezése protokollok, portok, hosztok és egyéb ügyfél által használt specifikus szolgáltatások alapján (VOIP, fontos szolgáltatásokkal rendelkező hosztok).
- A routerek eseményeinek monitorozásának és naplózásának megszervezése a műszaki támogató személyzet reagálására.
Ahogy értjük, bizonyos esetekben a műszaki specifikáció a követelményekből származik. Ezeket a követelményeket önállóan fogalmaztam meg, meghallgatva a fő problémákat. Lehetőségként feltételeztem, hogy ezek a feladatok mások által is elvégezhetők.
Milyen eszközöket fogunk használni a követelmények teljesítéséhez:
- ELK stack (egy idő után rájöttem, hogy a logstash helyett fluentd-t fogunk használni).
- Ansible. Az adminisztráció megkönnyítése és a hozzáférés elkülönítése érdekében AWX-et fogunk használni.
- GITLAB. Ezt nem szükséges magyarázni. Hol lenne a változáskezelés a konfigurációink nélkül.
- PowerShell. Lesz egy egyszerű szkript az első konfiguráció generálására.
- Dokumentáció írására és kézikönyvek létrehozására használt Doku wiki. Ebben az esetben a habr.com-ot használjuk.
- A monitorozás a zabbix segítségével fog történni. Ott készítjük el a kapcsolódási sémát a közös megértés érdekében.
EFK beállítási momentuma.
Az első pontról csak az indexek felépítésének ideológiáját írom le. Sok igazán
kiváló cikk van a mikrotik kezelő rendszerrel rendelkező eszközök naplózásának beállításáról és fogadásáról.
Néhány pontra kitérnék:
1. A séma szerint érdemes átgondolni a naplók fogadását különböző helyekről és különböző portokon. Ehhez napló aggregátort fogunk használni. Ezenkívül szeretnénk univerzális grafikonokat készíteni minden router számára a hozzáférés megosztásának lehetőségével. Akkor az indexeket a következőképpen építjük fel:
itt van egy részlet a fluentd konfigurációból type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Ily módon kombinálhatjuk a routereket és szegmentálhatjuk a terv szerint - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miért bonyolítanánk ezt? Megértjük, hogy több mint 200 eszközünk lesz. Mindezt nehéz követni. Az elasticsearch 6.8-as verziójától elérhetők a biztonsági beállítások (licenc vásárlása nélkül), így jogokat oszthatunk meg a műszaki támogatás munkatársai vagy a helyi rendszergazdák között.
Táblázatok, grafikonok - itt már egyszerűen meg kell állapodni - vagy egységesen használjuk, vagy mindenki azt csinál, ami neki kényelmes.
2. A naplózásról. Ha a tűzfal szabályaiban bekapcsoljuk a naplózást, akkor a neveket szóközök nélkül kell megadni. Szembetűnő, hogy egy egyszerű fluentd konfigurációval szűrhetjük az adatokat és kényelmes paneleket készíthetünk. Az alábbi képen - az én otthoni routerem.
3. A hely és a naplók kapcsán. Átlagosan, óránként 1000 üzenet mellett, a naplók napi 2-3 MB-ot foglalnak el, ami nem túl sok. Elasticsearch verzió: 7.5.
ANSIBLE.AWX
A szerencsénkre van готовый модуль для routeros
Megemlítettem az AWX-et, de az alábbi parancsok csak tiszta ansible-re vonatkoznak - úgy gondolom, akik dolgoztak az ansible-lal, nem fognak problémába ütközni az awx GUI használatával.
Őszintén bevallom, hogy korábban más útmutatókat néztem, ahol ssh-t használtak, és mindenkinek különböző problémái voltak a válaszidővel és egyéb problémákkal. Ismétlem, nem jutottam el a harcig, ezt az információt kísérletként kell felfogni, ami nem haladt tovább a 20 routerből álló standnál.
Használni kell a tanúsítványt vagy a fiókot. Itt önnek kell dönteni, én a tanúsítványok mellett állok. Van egy apró részlet a jogosultságokkal kapcsolatosan. Adok write jogot - legalább a "reset config"-ot nem lehet végrehajtani.
A tanúsítvány generálása, másolása és importálása során nem kellene problémáknak felmerülniük:
Röviden a parancsok listájaAz Ön számítógépén
ssh-keygen -t RSA, válaszoljunk a kérdésekre, mentjük a kulcsot.
Másolás a mikrotik-re:
felhasználó ssh-keys import public-key-file=id_mtx.pub felhasználó=ansible
Először létre kell hozni egy felhasználói fiókot és neki jogokat adni.
Ellenőrizzük a kapcsolatot tanúsítvány alapján
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Megnyitjuk 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
És itt egy példa 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
Ahogy a fenti konfigurációból látható, saját playbookot készíteni nem bonyolult dolog. Elegendő jól elsajátítani a mikrotik CLI-t. Tegyük fel a helyzetet, amikor az összes routeren el kell távolítani az address list-t a megadott adatokkal, akkor:
Megkeresni és törölni/ip firewal address-list remove [find where list=«gov.ru»]
Szándékosan nem tettem ide be az összes tűzfal beállítást, mivel ezek minden projektre egyediek. De egy biztos: csak címjegyzékeket használjatok.
A GITLAB minden világos. Nem fogok ezen a ponton megállni. Minden szép külön feladatokban, sablonokban, kezelőkben.
Powershell
Itt három fájl lesz. Miért powershell? Bármilyen eszköz választható a konfigurációk generálásához, akinek mi kényelmes. Jelen esetben mindenkinek Windows van a PC-jén, tehát miért csináljunk bash-ben, amikor kényelmesebb a powershell. Akinek mi kényelmes.
Magának a skriptnak a törzse (egyszerű és érthető):[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
Kérem, bocsássanak meg, nem tudom megosztani az összes szabályt, mert ez nem lenne túl szép. A szabályokat ti is megalkothatjátok a legjobb gyakorlatok alapján.
Például itt van egy hivatkozások listája, amelyet én is követtem::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — itt azt kell tudni, hogy a fasttrack bekapcsolásakor nem fognak működni a prioritási és sávszélesség-szabályok – hasznos gyenge eszközök számára.
A változók jelölése:A következő hálózatok szolgáltatják a példát:
192.168.0.0/24 munkahálózat
172.22.4.0/24 VOIP hálózat
10.0.0.0/24 a hálózat, amely nem fér hozzá a helyi hálózathoz
192.168.255.0/24 VPN hálózat nagy irodák számára
172.19.255.0/24 VPN hálózat kisebbek számára
A hálózat címe 4 tízes számjegyből áll, nevezetesen A.B.C.D formátumban, hasonló elven működik a csere; ha indításkor B-t kér, akkor a 192.168.0.0/24 hálózat esetében 0-t kell megadni, C-hez pedig = 0.
$EXTERNALIPADDRESS — a szolgáltatótól kapott dedikált cím.
$EXTERNALIPROUTE — az alapértelmezett útvonal a 0.0.0.0/0 hálózatra.
$BWorknets — Munkahálózat, amint ebben a példában lesz 168.
$CWorknets — Munkahálózat, amint ebben a példában lesz 0.
$BVoipNets — VOIP hálózat a példánkban itt 22
$CVoipNets — VOIP hálózat a példánkban itt 4
$CClientss — Ügyfélnetwork – kizárólag internet hozzáféréssel, a mi esetünkben itt 0
$BVPNWORKs — VPN hálózat nagyobb fiókok számára, a példánkban 20
$CVPNWORKs — VPN hálózat nagyobb fiókok számára, a példánkban 255
$BVPNCLIENTS — VPN hálózat kisebb fiókok számára, ami 19
$CVPNCLIENTS — VPN hálózat kisebb fiókok számára, ami 255
$NAMEROUTER — a router neve
$ServerCertificate — a tanúsítvány neve, amelyet előzetesen importálni kell
$infile — A fájl elérési útvonalát kell megadni, amelyből az konfigurációt olvassuk, például D:config.txt (jobb az angol útvonal idézőjelek és szóközök nélkül)
$outfile — meg kell adni az elérési utat, ahol menteni kell, például D:MT-test.txt
Szándékosan megváltoztattam a címeket a példákban érthető okokból.
Kihagytam a támadások és anomális viselkedés észlelését – ez egy külön cikket érdemel. De meg kell említeni, hogy ezen a területen használhatók a Zabbixból származó monitorozási adatok értékei + a curl-lel készített adatok az elasticsearch-mal.
Mire érdemes figyelmet fordítani:
- Hálózati terv. Jobb azonnal olvasható formában elkészíteni. Teljesen elegendő az excel. Sajnos, nagyon gyakran látom, hogy a hálózatokat a következő elv alapján készítik: "Megjelent egy új fiók, itt van nektek /24". Senki sem deríti ki, hány eszköz várható ezen a helyen, és lesz-e további növekedés. Például, ha egy kis bolt nyílik, amelynek eleve világos, hogy nem lesz több mint 10 eszköz, miért osztanánk ki a /24-et? A nagyobb fiókok esetében – éppen ellenkezőleg, /24-et osztanak ki, miközben az eszközök száma 500 – egyszerűen hozzá lehet adni a hálózatot, de szeretnénk mindent előre megtervezni.
- Szűrési szabályok. Ha a projekt előirányozza, hogy a hálózatokat szét kell választani és maximális szegmensezés szükséges. A legjobb gyakorlatok idővel változnak. Korábban külön hálózatot osztottak a számítógépek és a nyomtatók között, manapság teljesen normális, ha nem osztják ezeket a hálózatokat. Érdemes az egészséges észszel haladni, és nem kell sok alhálózatot létrehozni, ahol nincs szükség, és nem szabad egy hálózatba tömöríteni az összes eszközt.
- A "zöld" beállítások minden routeren. Tehát ha eldöntötted a tervet. Érdemes mindent azonnal figyelembe venni és igyekezni úgy beállítani, hogy minden beállítás azonos legyen - csak eltérő címjegyzék és IP címek legyenek. Problémák esetén az elhárítási idő rövidebb lesz.
- A szervezési kérdések legalább olyan fontosak, mint a technikai szempontok. Gyakran a lustább munkavállalók a megadott ajánlásokat "kézzel" valósítják meg, nem használva a kész konfigurációkat és szkripteket, ami végül problémahelyzetekhez vezet.
Dynamikus irányítási módszerrel. OSPF-t használtak zónális felosztással. De ez egy tesztkörnyezet, harci körülmények között sokkal izgalmasabb ilyen dolgokat beállítani.
Remélem, senki sem szomorkodik, amiért nem osztottam meg a routerek konfigurációit. Azt gondolom, hogy elegendőek a linkek, és innentől a követelményektől függ minden. És persze a tesztek, több tesztre van szükség.
Kívánok mindenkinek, hogy az új évben valósítsák meg projektjeiket. Legyen veletek az access granted!!!
Forrás: habr.com
