Sziasztok. Ez a cikk azoknak szól, akiknek sok Mikrotik eszköze van a flottájában, és akik maximális egységesítésre vágynak, hogy ne csatlakozzanak minden eszközhöz külön. Ebben a cikkben egy olyan projektet írok le, amely emberi tényezők miatt sajnos nem jutott harci körülmények közé. Röviden: több mint 200 router, gyors beállítás és személyzeti képzés, régiónkénti egységesítés, hálózatok és konkrét gazdagépek szűrése, szabályok egyszerű hozzáadásának lehetősége minden eszközhöz, naplózás és hozzáférés-szabályozás.
Az alábbiakban leírtak nem egy kész esetnek tűnnek, de remélem, hasznosak lesznek a hálózatok tervezése és a hibák minimalizálása során. Lehet, hogy néhány pont és megoldás nem tűnik teljesen helyesnek az Ön számára - ha igen, írja meg a megjegyzésekben. A kritika ebben az esetben élmény lesz a közös kincstár számára. Ezért, olvasó, vessen egy pillantást a megjegyzésekre, talán a szerző súlyos hibát követett el - a közösség segít.
A routerek száma 200-300, különböző városok között szétszórva, eltérő minőségű internetkapcsolattal. Mindent szépen kell csinálni, és egyértelműen el kell magyarázni a helyi rendszergazdáknak, hogyan fog működni minden.
Szóval hol kezdődik egy projekt? Természetesen azzal TK.
- Hálózati terv szervezése minden fiókra az ügyféligények szerint, hálózat szegmentálása (készülékszámtól függően fiókokban 3-20 hálózat).
- Eszközök beállítása minden ágban. A szolgáltató valós átviteli sebességének ellenőrzése különböző működési feltételek mellett.
- Eszközvédelem megszervezése, engedélyezési lista kezelése, támadások automatikus észlelése automatikus feketelistával egy bizonyos ideig, minimálisra csökkentve a hozzáférés ellenőrzésére és a szolgáltatás megtagadására használt különféle technikai eszközök használatát.
- Biztonságos VPN kapcsolatok szervezése hálózati szűréssel az ügyfelek igényei szerint. Minimum 3 VPN-kapcsolat minden ágtól a központba.
- Az 1., 2. pontok alapján. Válassza ki a hibatűrő VPN-ek felépítésének optimális módjait. Helyes indoklás esetén a dinamikus útválasztási technológiát a kivitelező választhatja meg.
- A forgalom prioritásainak megszervezése protokollok, portok, gazdagépek és az ügyfél által használt egyéb specifikus szolgáltatások szerint. (VOIP, házigazdák fontos szolgáltatásokkal)
- A forgalomirányító események figyelésének és naplózásának szervezése a műszaki támogató személyzet válaszadása érdekében.
Mint tudjuk, a műszaki előírásokat számos esetben a követelmények alapján állítják össze. Ezeket a követelményeket magam fogalmaztam meg, miután meghallgattam a főbb problémákat. Beismerte annak lehetőségét, hogy valaki más gondoskodhat ezekről a pontokról.
Milyen eszközöket kell használni a követelmények teljesítéséhez:
- ELK verem (egy idő után világossá vált, hogy a fluentd-t fogják használni a logstash helyett).
- Lehetséges. Az adminisztráció és a hozzáférés megosztásának megkönnyítése érdekében AWX-et fogunk használni.
- GITLAB. Itt nem kell magyarázkodni. Hol lennénk konfigurációink verzióvezérlése nélkül?
- PowerShell. Egy egyszerű szkript lesz a konfiguráció kezdeti generálásához.
- Doku wiki, dokumentációk és útmutatók írásához. Ebben az esetben a habr.com-ot használjuk.
- A monitorozás a zabbixon keresztül történik. Az általános érthetőség kedvéért ott egy csatlakozási rajz is készül.
EFK beállítási pontok
Az első ponttal kapcsolatban csak azt az ideológiát írom le, amely alapján az indexek felépülnek. Sokan vannak
kiváló cikkek a naplók beállításáról és fogadásáról a mikrotik-t futtató eszközökről.
Kitérek néhány pontra:
1. A diagram szerint érdemes megfontolni a naplók fogadását különböző helyekről és különböző portokon. Ehhez naplógyűjtőt fogunk használni. Univerzális grafikát szeretnénk készíteni minden útválasztóhoz, amely képes megosztani a hozzáférést. Ezután a következőképpen építjük fel az indexeket:
itt van egy darab a fluentd-vel rendelkező konfigurációból típusú elaszticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts : 9200
port 9200
Így tudunk routereket kombinálni és terv szerint szegmentálni - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miért kell ennyire bonyolulttá tenni? Megértjük, hogy 200 vagy több eszközünk lesz. Nem tudsz mindent nyomon követni. Az elasticsearch 6.8-as verziójával a biztonsági beállítások (licenc vásárlása nélkül) elérhetőek számunkra, ezáltal a megtekintési jogokat megoszthatjuk a technikai támogatás munkatársai vagy a helyi rendszergazdák között.
A táblázatok, grafikonok - itt csak meg kell állapodni - vagy ugyanazokat használják, vagy mindenki azt csinálja, ami neki kényelmes.
2. Naplózás útján. Ha engedélyezzük a bejelentkezést a tűzfalszabályokban, akkor a neveket szóközök nélkül készítjük el. Látható, hogy a fluentd-ben egy egyszerű konfig használatával adatokat szűrhetünk és kényelmes paneleket készíthetünk. Az alábbi képen az otthoni routerem látható.
3. Az elfoglalt hely és a rönkök szerint. Átlagosan 1000 üzenet/óra mellett a naplók napi 2-3 MB-ot foglalnak el, ami ugyebár nem is olyan sok. Elasticsearch 7.5 verzió.
ANSIBLE.AWX
Szerencsére van egy kész modulunk a routerekhez
Említettem az AWX-et, de az alábbi parancsok csak az ansible-ről szólnak tiszta formájában - szerintem aki már dolgozott az ansible-vel, annak nem lesz gondja az awx használatával a gui-n keresztül.
Hogy őszinte legyek, előtte megnéztem más útmutatókat, ahol ssh-t használtak, és mindegyiknek más-más problémája volt a válaszidővel és egy csomó más problémával. Ismétlem, nem jött össze a küzdelem , vedd ezt az információt kísérletnek, ami nem jutott tovább egy 20 routerből álló standnál.
Tanúsítványt vagy fiókot kell használnunk. Ön dönti el, én a bizonyítványokért vagyok. Néhány apró megjegyzés a jogokról. Írási jogot adok - legalább a „reset config” nem fog működni.
Nem lehet probléma a tanúsítvány generálásával, másolásával és importálásával:
Rövid parancslistaA számítógépén
ssh-keygen -t RSA, válaszoljon a kérdésekre, mentse el a kulcsot.
Másolás a mikroba:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Először létre kell hoznia egy fiókot, és hozzá kell rendelnie jogokat.
A kapcsolat ellenőrzése a tanúsítvány segítségével
ssh -p 49475 -i /keys/mtx [e-mail védett]
Regisztrálja a /etc/ansible/hosts címet
MT01 ansible_network_os=routerok ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routerok ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routerok ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routerok ansible_ssh_port=49475 ansible_ssh_user= ansible
Nos, egy példakönyv: - név: add_work_sites
hosts: testmt
sorozat: 1
kapcsolat: network_cli
remote_user: mikrotik.west
gyűjteni_tényeket: igen
feladatok:
- név: Munkahelyek hozzáadása
routeros_command:
parancsok:
— /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
Amint a fenti konfigurációból is látható, saját játékkönyvek létrehozása nem nehéz. Elég jól elsajátítani a cli mikrotikt. Képzeljünk el egy olyan helyzetet, amikor el kell távolítania a címlistát bizonyos adatokkal az összes útválasztóról, majd:
Keresse meg és távolítsa el/ip firewal address-list remove [find where list="gov.ru"]
Szándékosan nem tettem fel ide a teljes tűzfallistát, mert... projektenként egyedi lesz. De egy dolgot biztosan mondhatok, csak a címlistát használja.
A GITLAB szerint minden világos. Nem foglalkozom ezzel a kérdéssel. Minden szép az egyes feladatokhoz, sablonokhoz, kezelőkhöz.
PowerShell
Itt 3 fájl lesz. Miért powershell? Bármelyik eszközt kiválaszthatja a konfigurációk generálásához, amelyik kényelmesebb az Ön számára. Ebben az esetben mindenkinek Windows van a számítógépén, akkor miért csinálja ezt bash-ban, amikor a powershell kényelmesebb. Melyik a kényelmesebb?
Maga a szkript (egyszerű és érthető):[cmdletBinding()] Param(
[Paraméter(Kötelező=$igaz)] [string]$EXTERNALIPADDDRESS,
[Paraméter(Kötelező=$true)] [karakterlánc]$EXTERNALIPROUTE,
[Parameter(Kötelező=$igaz)] [string]$BWorknets,
[Parameter(Kötelező=$true)] [string]$CWorknets,
[Parameter(Kötelező=$true)] [string]$BVoipNets,
[Parameter(Kötelező=$true)] [string]$CVoipNets,
[Paraméter(Kötelező=$true)] [karakterlánc]$CClients,
[Paraméter(Kötelező=$true)] [karakterlánc]$BVPNWORKs,
[Parameter(Kötelező=$true)] [karakterlánc]$CVPNWORKs,
[Paraméter(Kötelező=$true)] [karakterlánc]$BVPNCLIENTS,
[Paraméter(Kötelező=$true)] [karakterlánc]$cVPNCLIENTS,
[Paraméter(Kötelező=$true)] [karakterlánc]$NAMEROUTER,
[Parameter(Kötelező=$true)] [string]$ServerCertificates,
[Parameter(Kötelező=$igaz)] [string]$infile,
[Paraméter(Kötelező=$igaz)] [karakterlánc]$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", $CClients)} |
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érlek, bocsáss meg, nem tudom közzétenni az összes szabályt, mert... nem lesz túl szép. A szabályokat saját maga is kitalálhatja, a bevált gyakorlatok alapján.
Itt van például az általam követett linkek listája::Securing_Your_Router
:IP/Tűzfal/Szűrő
:OSPF-példák
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack - itt tudnod kell, hogy ha a fasttrack be van kapcsolva, a forgalom prioritási és alakítási szabályai nem működnek - gyenge eszközök esetén hasznos.
A változók szimbólumai:A következő hálózatokat vesszük példaként:
192.168.0.0/24 működő hálózat
172.22.4.0/24 VOIP hálózat
10.0.0.0/24 hálózat a helyi hálózathoz való hozzáféréssel nem rendelkező ügyfelek számára
192.168.255.0/24 VPN hálózat nagy fióktelepekhez
172.19.255.0/24 VPN hálózat kicsiknek
A hálózati cím 4 decimális számból, illetve ABCD-ből áll, a csere ugyanezen az elven működik, ha indításkor B-t kér, akkor ez azt jelenti, hogy a 192.168.0.0/24 hálózatnál a 0-t, a C-nél pedig a 0-t kell beírni. = XNUMX.
$EXTERNALIPADDDRESS – dedikált cím a szolgáltatótól.
$EXTERNALIPROUTE - alapértelmezett útvonal a hálózathoz 0.0.0.0/0
$BWorknets - Munkahálózat, példánkban 168 lesz
$CWorknets - Működő hálózat, példánkban ez 0 lesz
$BVoipNets – VOIP hálózat a példánkban itt 22
$CVoipNets – VOIP hálózat a példánkban itt 4
$CClientss - Hálózat ügyfelek számára - Csak internet hozzáférés, esetünkben itt 0
$BVPNWORKs – VPN-hálózat nagy fióktelepekhez, 20. példánkban
$CVPNWORKs – VPN hálózat nagy fióktelepekhez, példánkban 255
$BVPNCLIENTS - VPN hálózat kis fióktelepekhez, azaz 19
$CVPNCLIENTS – VPN hálózat kis fióktelepekhez, azaz 255
$NAMEROUTER - router neve
$ServerCertificate – a korábban importált tanúsítvány neve
$infile — Adja meg annak a fájlnak az elérési útját, amelyből a konfigurációt ki fogjuk olvasni, például D:config.txt (lehetőleg az angol elérési út idézőjelek és szóközök nélkül)
$outfile — adja meg a mentési útvonalat, például D:MT-test.txt
Nyilvánvaló okokból szándékosan változtattam meg a példákban szereplő címeket.
Kihagytam a támadások és rendellenes viselkedés észlelésének lényegét – ez külön cikket érdemel. De érdemes kiemelni, hogy ebben a kategóriában használhatja a Zabbix monitorozási adatait + az elasticsearch feldolgozott göndörítési adatait.
Milyen pontokra kell figyelni:
- Hálózati terv. Érdemes azonnal, olvasható formában összeállítani. Excel elég lesz. Sajnos nagyon gyakran látom, hogy a hálózatok a „Megjelent egy új ág, itt a /24” elv szerint épülnek. Senki nem találja ki, hogy egy adott helyen hány készülék várható, vagy hogy lesz-e további növekedés. Például megnyílt egy kis bolt, ahol kezdetben egyértelmű volt, hogy az eszköz nem lesz több 10-nél, miért kell kiosztani a /24-et? A nagy fiókok esetében éppen ellenkezőleg, /24-et osztanak ki, és 500 eszköz van - egyszerűen hozzáadhat egy hálózatot, de mindent egyszerre szeretne átgondolni.
- Szűrési szabályok. Ha a projekt feltételezi a hálózatok szétválasztását és a maximális szegmentációt. A legjobb gyakorlatok idővel változnak. Korábban felosztották a PC-hálózatot és a nyomtatóhálózatot, de ma már teljesen normális, hogy ezeket a hálózatokat nem osztják szét. Érdemes a józan ésszel élni, és nem sok olyan alhálózatot létrehozni, ahol nincs rá szükség, és nem egyesíteni az összes eszközt egy hálózatba.
- „Arany” beállítások minden útválasztón. Azok. ha egy terv mellett döntött. Érdemes mindent azonnal előre látni, és megpróbálni megbizonyosodni arról, hogy minden beállítás azonos - csak a címlista és az IP-címek különböznek. Ha problémák merülnek fel, a hibakeresési idő rövidebb lesz.
- A szervezési kérdések nem kevésbé fontosak, mint a technikai kérdések. A lusta alkalmazottak gyakran „manuálisan” hajtják végre ezeket az ajánlásokat, kész konfigurációk és szkriptek használata nélkül, ami végül a semmiből vezet problémákhoz.
Dinamikus útválasztással. OSPF-et zónaosztással használtunk. De ez egy próbapad, harci körülmények között érdekesebb ilyen dolgokat konfigurálni.
Remélem senkit sem zavar, hogy nem tettem közzé a router konfigurációit. Szerintem elég lesz a link, aztán minden a követelményektől függ. És persze tesztekre, további vizsgálatokra van szükség.
Mindenkinek kívánom, hogy az új évben valósítsa meg projektjeit. Legyen veled a hozzáférés!!!
Forrás: will.com