Mia nefinita projekto. Reto de 200 MikroTik-enkursigiloj

Saluton al ĉiuj. Ĉi tiu artikolo estas destinita por tiuj, kiuj havas multajn Mikrotik-aparatojn en sia floto, kaj kiuj volas fari maksimuman unuiĝon por ne konekti al ĉiu aparato aparte. En ĉi tiu artikolo mi priskribos projekton, kiu bedaŭrinde ne atingis batalkondiĉojn pro homaj faktoroj. Resume: pli ol 200 enkursigiloj, rapida agordo kaj trejnado de dungitoj, unuiĝo laŭ regionoj, filtraj retoj kaj specifaj gastigantoj, la kapablo facile aldoni regulojn al ĉiuj aparatoj, registrado kaj alirkontrolo.

Kio estas priskribita malsupre ne ŝajnigas esti preta kazo, sed mi esperas, ke ĝi estos utila al vi kiam vi planas viajn retojn kaj minimumigi erarojn. Eble iuj punktoj kaj solvoj eble ne ŝajnas al vi tute ĝustaj - se jes, skribu en la komentoj. Kritiko ĉi-kaze estos sperto por la komuna trezorejo. Tial, leganto, rigardu la komentojn, eble la aŭtoro faris gravan eraron - la komunumo helpos.

La nombro da enkursigiloj estas 200-300, disigitaj tra diversaj urboj kun malsama kvalito de interretaj konektoj. Necesas fari ĉion bele kaj klare klarigi al lokaj administrantoj kiel ĉio funkcios.

Do, kie komenciĝas ia projekto? Kompreneble, kun TK.

1. Organizo de retoplano por ĉiuj branĉoj laŭ klientpostuloj, retsegmentado (de 3 ĝis 20 retoj en branĉoj depende de la nombro da aparatoj).
2. Agordi aparatojn en ĉiu branĉo. Kontrolante la realan trairon de la provizanto sub malsamaj operaciaj kondiĉoj.
3. Organizo de protektado de aparatoj, administrado de blanklisto, aŭtomata detekto de atakoj kun aŭtomata nigra listo dum certa tempo, minimumigante la uzon de diversaj teknikaj rimedoj uzataj por kapti kontrolan aliron kaj nei servon.
4. Organizo de sekuraj VPN-konektoj kun retfiltrado laŭ klientpostuloj. Minimume 3 VPN-konektoj de ĉiu branĉo al la centro.
5. Surbaze de punktoj 1, 2. Elektu la optimumajn manierojn konstrui misfunkciajn VPN-ojn. Se pravigite ĝuste, la dinamika vojigteknologio povas esti elektita fare de la entreprenisto.
6. Organizo de trafika prioritato per protokoloj, havenoj, gastigantoj kaj aliaj specifaj servoj uzataj de la kliento. (VOIP, gastigantoj kun gravaj servoj)
7. Organizo de monitorado kaj registrado de enkursigilo-eventoj por la respondo de teknika subtena personaro.

Kiel ni komprenas, en kelkaj kazoj la teknikaj specifoj estas ellaboritaj surbaze de la postuloj. Ĉi tiujn postulojn mi mem formulis, aŭskultinte la ĉefajn problemojn. Li akceptis la eblecon, ke iu alia povus prizorgi ĉi tiujn punktojn.

Kiuj iloj estos uzataj por plenumi ĉi tiujn postulojn:

1. ELK-stako (post iom da tempo, evidentiĝis, ke fluentd estos uzata anstataŭ logstash).
2. Ansible. Por facileco de administrado kaj aliro kundivido, ni uzos AWX.
3. GITLAB. Ne necesas klarigi ĉi tie. Kie ni estus sen versio-kontrolo de niaj agordoj?
4. PowerShell. Estos simpla skripto por la komenca generacio de la agordo.
5. Doku-vikio, por verki dokumentadon kaj gvidojn. En ĉi tiu kazo, ni uzas habr.com.
6. Monitorado estos farita per zabbix. Tie ankaŭ estos desegnita koneksa diagramo por ĝenerala kompreno.

EFK-agordaj punktoj

Pri la unua punkto, mi nur priskribos la ideologion per kiu la indeksoj estos konstruitaj. Estas multaj
bonegaj artikoloj pri agordo kaj ricevado de protokoloj de aparatoj, kiuj funkcias mikrotik.

Mi pritraktos kelkajn punktojn:

1. Laŭ la diagramo, indas konsideri ricevi ŝtipojn el diversaj lokoj kaj sur malsamaj havenoj. Por ĉi tio ni uzos protokolon. Ni ankaŭ volas fari universalajn grafikojn por ĉiuj enkursigiloj kun la kapablo dividi aliron. Tiam ni konstruas la indeksojn jene:

jen peco de la agordo kun fluentd tajpu elasticsearch
logstash_format vera
indekso_nomo mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
gastigantoj elasta serĉado: 9200
haveno 9200

Tiel ni povas kombini enkursigilojn kaj segmenti laŭ la plano - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Kial fari ĝin tiel komplika? Ni komprenas, ke ni havos 200 aŭ pli da aparatoj. Vi ne povas konservi trakon de ĉio. Kun versio 6.8 de elasticsearch, sekurecaj agordoj estas disponeblaj por ni (sen aĉeti permesilon), tiel ni povas distribui rigardrajtojn inter teknikaj subtenaj dungitoj aŭ lokaj sistemaj administrantoj.
Tabeloj, grafikaĵoj - ĉi tie vi nur bezonas konsenti - aŭ uzi la samajn, aŭ ĉiu faras tion, kio estas oportuna por li.

2. Per arbohakado. Se ni ebligas ensaluti la fajroŝirmigajn regulojn, tiam ni faras la nomojn sen spacoj. Oni povas vidi, ke uzante simplan agordon en fluentd, ni povas filtri datumojn kaj fari oportunajn panelojn. La suba bildo estas mia hejma enkursigilo.

3. Per spaco okupita kaj ŝtipoj. Averaĝe, kun 1000 mesaĝoj hore, protokoloj okupas 2-3 MB tage, kio, vi vidas, ne tiom multe. Elasticsearch-versio 7.5.

ANSIBLE.AWX

Feliĉe por ni, ni havas pretan modulon por routeroj
Mi menciis pri AWX, sed la subaj komandoj temas nur pri ansible en ĝia pura formo - mi pensas, ke por tiuj, kiuj laboris kun ansible, ne estos problemoj uzante awx per la gui.

Por esti honesta, antaŭ ĉi tio mi rigardis aliajn gvidistojn kie ili uzis ssh, kaj ili ĉiuj havis malsamajn problemojn kun respondtempo kaj amason da aliaj problemoj. Mi ripetas, ĝi ne venis al batalo , prenu ĉi tiun informon kiel eksperimenton, kiu ne alvenis pli ol stando de 20 enkursigiloj.

Ni devas uzi atestilon aŭ konton. Estas al vi decidi, mi estas por atestiloj. Iu subtila punkto pri rajtoj. Mi donas skribrajtojn - almenaŭ "restarigi agordon" ne funkcios.

Ne devus esti problemoj por generi, kopii kaj importi la atestilon:

Mallonga komanda listoSur via komputilo
ssh-keygen -t RSA, respondu demandojn, konservu la ŝlosilon.
Kopiu al mikrotik:
uzanto ssh-keys import public-key-file=id_mtx.pub uzanto=ansible
Unue vi devas krei konton kaj atribui rajtojn al ĝi.
Kontrolante la konekton per la atestilo
ssh -p 49475 -i /keys/mtx [retpoŝte protektita]

Registru 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

Nu, ekzempla ludlibro: - nomo: add_work_sites
gastigantoj: testmt
serialo: 1
konekto: network_cli
fora_uzanto: mikrotik.west
gather_facts: jes
taskoj:
- nomo: aldonu Work_sites
routeros_command:
ordonoj:
— /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

Kiel vi povas vidi el la supra agordo, krei viajn proprajn ludlibrojn ne estas malfacila. Sufiĉas bone regi cli mikrotik. Ni imagu situacion, kie vi devas forigi la adresliston kun certaj datumoj sur ĉiuj enkursigiloj, tiam:

Trovu kaj forigu/ip firewal adreso-listo forigi [trovu kie listo = "gov.ru"]

Mi intence ne inkludis la tutan fajroŝirmilon-liston ĉi tie ĉar... ĝi estos individua por ĉiu projekto. Sed unu aferon mi povas diri certe, uzu nur la adresliston.

Laŭ GITLAB ĉio estas klara. Mi ne traktos ĉi tiun punkton. Ĉio estas bela por individuaj taskoj, ŝablonoj, prizorgantoj.

PowerShell

Ĉi tie estos 3 dosieroj. Kial powershell? Vi povas elekti ajnan ilon por generi agordojn, kio ajn estas pli oportuna por vi. En ĉi tiu kazo, ĉiuj havas Vindozon sur sia komputilo, do kial fari ĝin en bash kiam Powershell estas pli oportuna. Kiu estas pli oportuna?

La skripto mem (simpla kaj komprenebla):[cmdletBinding ()] Param(
[Parametro(Deviga=$vera)] [ĉeno]$EXTERNALIPADDRESS,
[Parametro(Deviga=$vera)] [ĉeno]$EXTERNALIPROUTE,
[Parametro(Deviga=$vera)] [ĉeno]$BWorknets,
[Parametro(Deviga=$vera)] [ĉeno]$CWorknets,
[Parametro(Deviga=$vera)] [ĉeno]$BVoipNets,
[Parametro(Deviga=$vera)] [ĉeno]$CVoipNets,
[Parametro(Deviga=$vera)] [ĉeno]$CClients,
[Parametro(Deviga=$vera)] [ĉeno]$BVPNWORK-oj,
[Parametro(Deviga=$vera)] [ĉeno]$CVPNWORK-oj,
[Parametro(Deviga=$vera)] [ĉeno]$BVPNCLIENTS-oj,
[Parametro(Deviga=$vera)] [ĉeno]$cVPNCLIENTS-oj,
[Parametro(Deviga=$vera)] [ĉeno]$NAMEROUTER,
[Parametro(Deviga=$vera)] [ĉeno]$ServerCertificates,
[Parametro(Deviga=$vera)] [ĉeno]$endosiero,
[Parametro(Deviga=$vera)] [ĉeno]$eldosiero
)

Get-Enhavo $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Anstataŭigi("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Objekto {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Objekto {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Objekto {$_.Replace("CClients", $CClientss)} |
Foreach-Objekto {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Objekto {$_.Anstataŭigi("CVPNWORK", $CVPNWORK-oj)} |
Foreach-Objekto {$_.Replace("BVPNCLIENTS", $BVPNCLIENTS)} |
Foreach-Objekto {$_.Anstataŭigi("CVPNCLIENTS", $cVPNCLIENTS)} |
Foreach-Object {$_.Anstataŭigi("MYNAMEROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("Servilo-Atestilo", $Servilo-Atestiloj)} | Aro-Enhavo $eldosiero

Bonvolu pardoni min, mi ne povas afiŝi ĉiujn regulojn ĉar... ĝi ne estos tre bela. Vi povas mem elpensi la regulojn, gvidate de plej bonaj praktikoj.

Ekzemple, jen listo de ligiloj, kiujn mi sekvis:wiki.mikrotik.com/wiki/Manual:Sekurigi_Vian_Enkursigilon
wiki.mikrotik.com/wiki/Manual:IP/Fajromuro/Filtrilo
wiki.mikrotik.com/wiki/Manual:OSPF-ekzemploj
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 - ĉi tie vi devas scii, ke kiam fasttrack estas ebligita, la trafikaj prioritataj kaj formaj reguloj ne funkcios - utilaj por malfortaj aparatoj.

Simboloj por variabloj:La sekvaj retoj estas prenitaj kiel ekzemplo:
192.168.0.0/24 funkcianta reto
172.22.4.0/24 VOIP-reto
10.0.0.0/24 reto por klientoj sen aliro al la loka reto
192.168.255.0/24 VPN-reto por grandaj branĉoj
172.19.255.0/24 VPN-reto por malgrandaj

La retadreso konsistas el 4 dekumaj nombroj, respektive A.B.C.D, la anstataŭigo funkcias laŭ la sama principo, se ĉe ekfunkciigo ĝi petas B, tiam tio signifas, ke vi devas enigi la numeron 192.168.0.0 por la reto 24/0, kaj por C. = 0.
$EXTERNALIPADDRESS - dediĉita adreso de la provizanto.
$EXTERNALIPROUTE - defaŭlta itinero al reto 0.0.0.0/0
$BWorknets - Laborreto, en nia ekzemplo estos 168
$CWorknets - Laboranta reto, en nia ekzemplo ĉi tio estos 0
$BVoipNets - VOIP-reto en nia ekzemplo ĉi tie 22
$CVoipNets - VOIP-reto en nia ekzemplo ĉi tie 4
$CClientss - Reto por klientoj - nur interreta aliro, en nia kazo ĉi tie 0
$BVPNWORKs - VPN-reto por grandaj branĉoj, en nia ekzemplo 20
$CVPNWORKs - VPN-reto por grandaj branĉoj, en nia ekzemplo 255
$BVPNCLIENTS - VPN-reto por malgrandaj branĉoj, tio signifas 19
$CVPNCLIENTS - VPN-reto por malgrandaj branĉoj, tio signifas 255
$NAMEROUTER - nomo de enkursigilo
$ServerCertificate - la nomo de la atestilo, kiun vi antaŭe importis
$infile — Indiku la vojon al la dosiero el kiu ni legos la agordon, ekzemple D:config.txt (prefere la anglan vojon sen citiloj kaj spacoj)
$eldosiero — specifu la vojon kie konservi ĝin, ekzemple D:MT-test.txt

Mi intence ŝanĝis la adresojn en la ekzemploj pro evidentaj kialoj.

Mi maltrafis la punkton pri detektado de atakoj kaj anomalia konduto - ĉi tio meritas apartan artikolon. Sed indas atentigi, ke en ĉi tiu kategorio vi povas uzi monitorajn datumajn valorojn de Zabbix + prilaboritaj buklaj datumoj de elasticsearch.

Kiajn punktojn vi devas atenti:

1. Reta plano. Estas pli bone formi ĝin tuj en legebla formo. Excel sufiĉos. Bedaŭrinde, mi tre ofte vidas, ke retoj estas konstruitaj laŭ la principo "Nova branĉo aperis, jen /24 por vi." Neniu eltrovas kiom da aparatoj estas atendataj en difinita loko aŭ ĉu estos plia kresko. Ekzemple, malgranda vendejo malfermiĝis en kiu komence estis klare, ke la aparato estus ne pli ol 10, kial asigni /24? Por grandaj branĉoj, male, ili asignas /24, kaj estas 500 aparatoj - vi povas simple aldoni reton, sed vi volas pripensi ĉion samtempe.
2. Filtraj reguloj. Se la projekto supozas, ke estos apartigo de retoj kaj maksimuma segmentado. Plej bonaj Praktikoj ŝanĝiĝas laŭlonge de la tempo. Antaŭe, komputila reto kaj presila reto estis dividitaj, sed nun estas tute normale ne dividi ĉi tiujn retojn. Indas uzi komunan prudenton kaj ne krei multajn subretojn kie ili ne estas bezonataj kaj ne kombini ĉiujn aparatojn en unu reton.
3. "Oraj" agordoj sur ĉiuj enkursigiloj. Tiuj. se vi decidis pri plano. Indas antaŭvidi ĉion tuj kaj provi certigi, ke ĉiuj agordoj estas identaj - nur la adreslisto kaj IP-adresoj estas malsamaj. Se aperos problemoj, sencimiga tempo estos malpli.
4. Organizaj aferoj ne estas malpli gravaj ol teknikaj. Ofte maldiligentaj dungitoj plenumas ĉi tiujn rekomendojn "mane", sen uzi pretajn agordojn kaj skriptojn, kio finfine kondukas al problemoj de nenie.

Per dinamika vojigo. OSPF kun zondividado estis uzita. Sed ĉi tio estas testbenko; estas pli interese starigi tiajn aferojn en batalkondiĉoj.

Mi esperas, ke neniu ĉagreniĝas, ke mi ne afiŝis la agordojn de la enkursigilo. Mi pensas, ke la ligiloj sufiĉos, kaj tiam ĉio dependas de la postuloj. Kaj kompreneble provoj, pli da provoj estas necesaj.

Mi deziras, ke ĉiuj realigu siajn projektojn en la nova jaro. Ke aliro donita estu kun vi!!!

fonto: www.habr.com