Tere kõigile. See artikkel on mõeldud neile, kelle autopargis on palju Mikrotiku seadmeid ja kes soovivad teha maksimaalset ühtlust, et mitte ühendada iga seadmega eraldi. Selles artiklis kirjeldan projekti, mis inimtegurite tõttu kahjuks lahingutingimustesse ei jõudnud. Lühidalt: üle 200 ruuteri, kiire seadistamine ja töötajate väljaõpe, ühendamine piirkondade kaupa, võrkude ja konkreetsete hostide filtreerimine, võimalus hõlpsasti lisada reegleid kõikidele seadmetele, logimine ja juurdepääsu kontroll.
Allpool kirjeldatu ei pretendeeri valmisjuhtumile, kuid loodan, et see on teile võrkude planeerimisel ja vigade minimeerimisel kasulik. Võib-olla ei tundu mõned punktid ja lahendused teile täiesti õiged - kui jah, siis kirjutage kommentaaridesse. Kriitika on sel juhul elamus ühisele riigikassale. Seetõttu, lugeja, vaadake kommentaare, võib-olla tegi autor tõsise vea - kogukond aitab.
Ruuterite arv on 200-300, mis on hajutatud erinevatesse linnadesse erineva kvaliteediga Interneti-ühendustega. Kõik on vaja teha ilusti ja kohalikele administraatoritele selgelt selgitada, kuidas kõik töötab.
Niisiis, kust ükski projekt algab? Muidugi koos TK.
- Kõigi filiaalide võrguplaani koostamine vastavalt kliendi nõudmistele, võrgu segmenteerimine (3 kuni 20 võrku kontorites sõltuvalt seadmete arvust).
- Seadmete seadistamine igas harus. Pakkuja tegeliku läbilaskevõime kontrollimine erinevates töötingimustes.
- Seadme kaitse korraldamine, valge nimekirja haldamine, rünnakute automaatne tuvastamine teatud aja jooksul automaatse musta nimekirja lisamisega, minimeerides erinevate tehniliste vahendite kasutamist, mida kasutatakse juurdepääsu kontrollimiseks ja teenuse keelamiseks.
- Turvaliste VPN-ühenduste korraldamine koos võrgu filtreerimisega vastavalt kliendi nõudmistele. Igast harust keskusesse vähemalt 3 VPN-ühendust.
- Tuginedes punktidele 1, 2. Valige optimaalsed viisid veakindlate VPN-ide loomiseks. Kui see on õigesti põhjendatud, saab dünaamilise marsruutimise tehnoloogia valida töövõtja.
- Liikluse prioriseerimise korraldamine protokollide, portide, hostide ja muude kliendi poolt kasutatavate spetsiifiliste teenuste järgi. (VOIP, oluliste teenustega hostid)
- Ruuteri sündmuste jälgimise ja logimise korraldamine tehnilise tugipersonali reageerimiseks.
Nagu me mõistame, koostatakse tehnilised kirjeldused paljudel juhtudel nõuetest lähtuvalt. Sõnastasin need nõuded ise, olles ära kuulanud põhiprobleemid. Ta tunnistas võimalust, et keegi teine võiks nende punktide eest hoolitseda.
Milliseid tööriistu nende nõuete täitmiseks kasutatakse:
- ELK virn (mõne aja pärast sai selgeks, et logstashi asemel kasutatakse fluentd).
- Võimalik. Haldamise ja juurdepääsu jagamise hõlbustamiseks kasutame AWX-i.
- GITLAB. Siin pole vaja seletada. Kus me oleksime ilma oma konfiguratsioonide versioonikontrollita?
- PowerShell. Konfiguratsiooni esialgseks genereerimiseks on lihtne skript.
- Doku wiki dokumentatsiooni ja juhendite kirjutamiseks. Sel juhul kasutame veebisaiti habr.com.
- Seire viiakse läbi zabbixi kaudu. Üldise arusaamise huvides joonistatakse sinna ka ühendusskeem.
EFK seadistuspunktid
Esimese punkti osas kirjeldan vaid ideoloogiat, mille järgi indekseid üles ehitatakse. Seal on palju
suurepärased artiklid logide seadistamise ja vastuvõtmise kohta seadmetest, mis töötavad mikrotik.
Ma peatun mõnel punktil:
1. Skeemi järgi tasub kaaluda logide vastuvõtmist erinevatest kohtadest ja erinevatest sadamatest. Selleks kasutame logide koondajat. Samuti tahame teha universaalse graafika kõigi ruuterite jaoks, millel on võimalus juurdepääsu jagada. Seejärel koostame indeksid järgmiselt:
siin on tükk fluentd-iga konfiguratsioonist tüüp elastsearch
logstash_format true
indeksi_nimi mikrotiklogs.north
logstash_prefix mikrotiklogs.north
loputusintervall 10s
hosts : 9200
port 9200
Nii saame ruutereid kombineerida ja plaani järgi segmentida - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miks teha see nii keeruliseks? Mõistame, et meil on 200 või enam seadet. Sa ei saa kõike jälgida. Elasticsearchi versiooniga 6.8 on turvaseaded meile kättesaadavad (ilma litsentsi ostmata), seega saame jagada vaatamisõigusi tehnilise toe töötajate või kohalike süsteemiadministraatorite vahel.
Tabelid, graafikud - siin peate lihtsalt kokku leppima - kas kasutage samu või igaüks teeb seda, mis talle sobib.
2. Logimisega. Kui lubame tulemüürireeglites sisselogimise, siis teeme nimed ilma tühikuteta. On näha, et kasutades lihtsat konfiguratsiooni fluentd-s, saame andmeid filtreerida ja teha mugavaid paneele. Alloleval pildil on minu kodu ruuter.
3. Hõivatud ruumi ja palkide järgi. Keskmiselt võtavad logid 1000 sõnumiga tunnis 2-3 MB päevas, mis, näete, polegi nii palju. Elasticsearchi versioon 7.5.
ANSIBLE.AWX
Meie õnneks on meil ruuterite jaoks valmis moodul
Mainisin AWX-i kohta, kuid allolevad käsud on ainult puhtal kujul ansible kohta - arvan, et neil, kes on ansiblega töötanud, ei teki probleeme awx-i kasutamisel läbi gui.
Ausalt öeldes vaatasin enne seda teisi juhendeid, kus nad kasutasid ssh-d, ja neil kõigil oli erinevaid probleeme reageerimisajaga ja hunnik muid probleeme. Kordan, see ei tulnud tülli , võtke seda teavet kui katset, mis ei jõudnud kaugemale kui 20 ruuterist koosnev stend.
Peame kasutama sertifikaati või kontot. See on teie otsustada, mina olen sertifikaatide poolt. Mõni peen punkt õiguste kohta. Annan kirjutamisõigused - vähemalt "reset config" ei tööta.
Sertifikaadi genereerimisel, kopeerimisel ja importimisel ei tohiks probleeme tekkida:
Lühike käskude loeteluTeie arvutis
ssh-keygen -t RSA, vasta küsimustele, salvesta võti.
Kopeeri mikrokusse:
kasutaja ssh-keys import public-key-file=id_mtx.pub user=ansible
Kõigepealt peate looma konto ja määrama sellele õigused.
Ühenduse kontrollimine sertifikaadi abil
ssh -p 49475 -i /keys/mtx [meiliga kaitstud]
Registreerige vi /etc/ansible/hosts
MT01 ansible_network_os=ruuterid ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=ruuterid ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=ruuterid ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=ruuterid ansible_ssh_port=49475 ansible_ssh_user= ansible
Noh, näide mänguraamatust: - nimi: add_work_sites
hosts: testmt
seeria: 1
ühendus: network_cli
remote_user: mikrotik.west
koguda_facts: jah
ülesanded:
- nimi: lisage töökohad
routeros_command:
käsud:
— /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
Nagu ülaltoodud konfiguratsioonist näete, pole oma mänguraamatute loomine keeruline. Piisab cli mikrotiku hästi valdamisest. Kujutagem ette olukorda, kus peate kõigi ruuterite teatud andmetega aadressiloendi eemaldama, siis:
Otsige üles ja eemaldage/ip tulemüüri aadressiloend eemalda [leida kust list="gov.ru"]
Ma ei lisanud siia tahtlikult kogu tulemüüri loendit, sest... see on iga projekti puhul individuaalne. Kuid ühte võin kindlalt öelda, kasutage ainult aadresside loendit.
GITLABi järgi on kõik selge. Ma ei hakka sellel teemal pikemalt peatuma. Üksikute ülesannete, mallide, töötlejate jaoks on kõik ilus.
PowerShell
Siin on 3 faili. Miks powershell? Konfiguratsioonide loomiseks saate valida mis tahes tööriista, mis teile mugavam on. Sel juhul on kõigil arvutis Windows, miks siis teha seda bashis, kui powershell on mugavam. Kumb on mugavam?
Skript ise (lihtne ja arusaadav):[cmdletBinding()] Param(
[Parameeter(kohustuslik=$true)] [string]$EXTERNALIPADDDRESS,
[Parameeter(kohustuslik=$true)] [string]$EXTERNALIPROUTE,
[Parameeter(kohustuslik=$true)] [string]$BWorknets,
[Parameeter(kohustuslik=$true)] [string]$CWorknets,
[Parameeter(kohustuslik=$true)] [string]$BVoipNets,
[Parameeter(kohustuslik=$true)] [string]$CVoipNets,
[Parameeter(kohustuslik=$true)] [string]$CClients,
[Parameeter(kohustuslik=$true)] [string]$BVPNWORKs,
[Parameeter(kohustuslik=$true)] [string]$CVPNWORKs,
[Parameeter(kohustuslik=$true)] [string]$BVPNCLIENTS,
[Parameeter(kohustuslik=$true)] [string]$cVPNCLIENTS,
[Parameeter(kohustuslik=$true)] [string]$NAMEROUTER,
[Parameeter(kohustuslik=$true)] [string]$ServerCertificates,
[Parameeter(kohustuslik=$true)] [string]$infile,
[Parameeter(kohustuslik=$true)] [string]$outfile
)
Hangi sisu $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", $BVPNCLIENTS)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Palun andke andeks, ma ei saa kõiki reegleid postitada, sest... see ei saa väga ilus olema. Saate reeglid ise koostada, juhindudes parimatest tavadest.
Näiteks siin on nimekiri linkidest, mida ma järgisin::Teie_ruuteri turvamine
:IP/tulemüür/filter
:OSPF-näited
: Winbox
:Upgrading_RouterOS
:IP/Fasttrack – siin pead teadma, et kui kiirtee on lubatud, siis liikluse prioriseerimise ja kujundamise reeglid ei tööta – kasulik nõrkade seadmete puhul.
Muutujate sümbolid:Näitena on võetud järgmised võrgud:
192.168.0.0/24 töötav võrk
172.22.4.0/24 VOIP-võrk
10.0.0.0/24 võrk klientidele, kellel puudub juurdepääs kohalikule võrgule
192.168.255.0/24 VPN-võrk suurtele filiaalidele
172.19.255.0/24 VPN-võrk väikestele
Võrguaadress koosneb 4 kümnendnumbrist, vastavalt ABCD, asendus töötab samal põhimõttel, kui käivitamisel küsib B, siis see tähendab, et peate sisestama numbri 192.168.0.0 võrgu 24/0 ja C jaoks = 0.
$EXTERNALIPADDDRESS – teenusepakkuja spetsiaalne aadress.
$EXTERNALIPROUTE – vaikemarsruut võrku 0.0.0.0/0
$BWorknets – töövõrk, meie näites on 168
$CWorknets – töötav võrk, meie näites on see 0
$BVoipNets – VOIP-võrk meie näites siin 22
$CVoipNets – VOIP-võrk meie näites siin 4
$CClientss - võrk klientidele - ainult Interneti-juurdepääs, meie puhul siin 0
$BVPNWORKs – VPN-võrk suurte filiaalide jaoks, meie näites 20
$CVPNWORKs – VPN-võrk suurte filiaalide jaoks, meie näites 255
$BVPNCLIENTS – VPN-võrk väikestele filiaalidele, mis tähendab 19
$CVPNCLIENTS – VPN-võrk väikeste filiaalide jaoks, mis tähendab 255
$NAMEROUTER – ruuteri nimi
$ServerCertificate – varem imporditud sertifikaadi nimi
$infile — määrake tee failini, kust me konfiguratsiooni loeme, näiteks D:config.txt (eelistatavalt ingliskeelne tee ilma jutumärkide ja tühikuteta)
$outfile — määrake tee, kuhu see salvestada, näiteks D:MT-test.txt
Olen arusaadavatel põhjustel näidetes aadresse teadlikult muutnud.
Rünnakute ja anomaalse käitumise tuvastamise kohta jäi mul tähelepanuta – see väärib eraldi artiklit. Kuid tasub märkida, et selles kategoorias saate kasutada Zabbixi jälgimisandmete väärtusi + elasticsearchi töödeldud lokkide andmeid.
Millistele punktidele peaksite tähelepanu pöörama:
- Võrguplaan. Parem on see kohe loetavas vormis koostada. Excelist piisab. Kahjuks näen väga sageli, et võrke ehitatakse põhimõttel "Uus haru on ilmunud, siin on /24 teile." Keegi ei arva, kui palju seadmeid antud asukohas oodata on või kas kasvu on veelgi oodata. Näiteks avati väike pood, kus alguses oli selge, et seadet pole rohkem kui 10, milleks eraldada /24? Suurte filiaalide jaoks eraldavad nad vastupidi /24 ja seadmeid on 500 - saate lihtsalt võrgu lisada, kuid soovite kõik korraga läbi mõelda.
- Filtreerimise reeglid. Kui projekt eeldab võrkude eraldamist ja maksimaalset segmenteerimist. Parimad tavad muutuvad aja jooksul. Kui varem jagati arvutivõrku ja printerivõrku, siis nüüd on täiesti normaalne neid võrke mitte jagada. Tasub kasutada tervet mõistust ja mitte luua palju alamvõrke, kus neid pole vaja, ja mitte kombineerida kõiki seadmeid ühte võrku.
- Kõigi ruuterite kuldsed sätted. Need. kui olete plaani kasuks otsustanud. Tasub kõike kohe ette näha ja püüda veenduda, et kõik seaded on identsed – erinevad on ainult aadresside loend ja IP-aadressid. Probleemide ilmnemisel väheneb silumisaeg.
- Organisatsioonilised küsimused pole vähem tähtsad kui tehnilised. Sageli täidavad laisad töötajad neid soovitusi "käsitsi", ilma valmiskonfiguratsioone ja skripte kasutamata, mis lõpuks põhjustab probleeme eikusagilt.
Dünaamilise marsruutimise abil. Kasutati tsoonijaotusega OSPF-i. Kuid see on katsestend, huvitavam on selliseid asju lahingutingimustes seadistada.
Loodan, et keegi ei ole ärritunud, et ma ruuteri konfiguratsioone ei postitanud. Arvan, et linkidest piisab ja siis oleneb kõik nõuetest. Ja muidugi testid, rohkem teste on vaja.
Soovin kõigile uuel aastal oma projektid ellu viia. Lubatud juurdepääs olgu teiega!!!
Allikas: www.habr.com