Salutare tuturor. Acest articol se adresează celor care au un parc mare de dispozitive MikroTik și doresc să realizeze o unificare maximă, pentru a nu trebui să se conecteze la fiecare dispozitiv în parte. În acest articol voi descrie un proiect care, din păcate, nu a ajuns în condiții de operare din cauza unor factori umani. Pe scurt: peste 200 de routere, configurare rapidă și instruire a personalului, unificare pe regiuni, filtrarea rețelelor și a anumitor hosts, posibilitatea de a adăuga ușor reguli pe toate dispozitivele, înregistrare și control al accesului.
Ceea ce este descris mai jos nu se pretează la a fi un caz gata formulat, dar sper să vă fie util în planificarea propriilor rețele și minimizarea erorilor. Este posibil ca unele puncte și soluții să vi se pară nu tocmai corecte - dacă este așa, vă rugăm să scrieți în comentarii. Critica în acest caz va contribui la experiența colectivă. Așadar, cititorule, aruncă o privire în comentarii, poate autorul a comis o eroare gravă - comunitatea va ajuta.
Numărul de routere variază între 200-300, fiind dispersate în diferite orașe cu calitate variată a conexiunii la internet. Este necesar să facem totul să arate bine și să explicăm accesibil administratorilor locali cum va funcționa totul.
Deci, cu ce începe orice proiect. Desigur, cu Caiet de sarcini.
- Organizarea planului rețelei pentru toate filialele conform cerințelor clientului, segmentarea rețelelor (de la 3 la 20 de rețele în filiale, în funcție de numărul de dispozitive).
- Configurarea dispozitivelor în fiecare filială. Verificarea viteză de transfer reală a furnizorului în diferite condiții de lucru.
- Organizarea protecției dispozitivelor, gestionarea pe bază de whitelist, detectarea automată a atacurilor cu adăugarea automată în blacklist pentru o anumită perioadă de timp, minimizarea utilizării diverselor mijloace tehnice utilizate pentru interceptarea accesului la control și renunțarea la întreținere.
- Organizarea conexiunilor vpn securizate cu filtrare pe rețele conform cerințelor clientului. Minimum 3 conexiuni vpn din fiecare filială către centrul de operațiuni.
- Pe baza punctelor 1 și 2. Alegeți cele mai optime rute pentru construirea unor conexiuni vpn redundante. Tehnologia de rutare dinamică poate fi aleasă de executor cu o justificare corectă.
- Organizarea prioritizării traficului pe baza protocoalelor, porturilor, gazdelor și altor servicii specifice utilizate de client. (VOIP, gazde cu servicii importante)
- Organizarea monitorizării și înregistrării evenimentelor routerelor pentru a răspunde echipei de suport tehnic.
Așa cum înțelegem, în unele cazuri caietul de sarcini este redactat pe baza cerințelor. Aceste cerințe le-am formulat personal, ascultând problemele principale. Am considerat posibilitatea ca îndeplinirea acestor puncte să fie realizată de altcineva.
Ce instrumente vor fi utilizate pentru a îndeplini aceste cerințe:
- Stiva ELK (după un timp, a venit înțelegerea că în loc de logstash va fi folosit fluentd).
- Ansible. Pentru confortul administrării și separarea accesului, vom folosi AWX.
- GITLAB. Aici nu trebuie să explicăm. Unde altundeva am putea avea control asupra versiunilor configurațiilor noastre.
- PowerShell. Va exista un script simplu pentru generarea inițială a configurației.
- Doku wiki, pentru redactarea documentației și ghidurilor. În acest caz, utilizăm habr.com.
- Monitorizarea va fi realizată prin zabbix. Acolo va fi desenată și schema conexiunilor pentru o înțelegere generală.
Aspectele configurării EFK
Pentru primul punct, voi descrie doar ideologia conform căreia vor fi construite indecșii. Există multe
articole minunate despre configurarea și primirea logurilor de la dispozitivele gestionate de mikrotik.
Mă voi concentra asupra unor aspecte:
1. Conform schemei, este necesar să ne gândim la primirea logurilor din diferite locuri și pe diferite porturi. Pentru aceasta, vom folosi un agregator de loguri. De asemenea, ne dorim să creăm grafice universale pentru toate routerele cu posibilitatea de a separa accesul. Atunci construim indecșii în felul următor:
Iată un fragment de configurare cu fluentd tip elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
gazde :9200
port 9200
Astfel, putem uni routerele și segmenta conform planului - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. De ce să complicăm atât? Înțelegem că vom avea 200 de dispozitive sau mai multe. Nu putem urmări totul. Cu versiunea 6.8 de elasticsearch, avem disponibile setările de securitate (fără a cumpăra o licență), astfel putem distribui drepturile de vizualizare între angajații de suport tehnic sau administratorii sistemici locali.
Tabele, grafice – aici trebuie doar să ne înțelegem: fie folosim un mod uniform, fie fiecare face așa cum îi este mai comod.
2. Referitor la logare. Dacă activăm log-urile în regulile firewall-ului, denumirile trebuie să fie fără spații. Se vede că, folosind o configurație simplă în fluentd, putem filtra datele și crea panouri convenabile. În imaginea de mai jos - routerul meu de acasă.
3. Despre spațiul ocupat și log-uri. În medie, la 1000 de mesaje pe oră, log-urile ocupă între 2-3 mb pe zi, ceea ce, să recunoaștem, nu este atât de mult. Versiunea elasticsearch 7.5.
ANSIBLE.AWX
Din fericire, avem un modul gata pentru routeros.
Am menționat despre AWX, dar comenzile de mai jos țin doar de ansible în forma sa pură – cred că pentru cei care au lucrat cu ansible, nu vor exista probleme în utilizarea prin gui awx.
Trebuie să mărturisesc că înainte am vizionat alte ghiduri, unde au folosit ssh și toți au avut probleme diferite cu timpul de răspuns și multe alte probleme. Reiterez, nu am ajuns la o confruntare :), considerați această informație ca un experiment, care nu a avansat mai departe de un stand cu 20 de routere.
Trebuie să utilizăm un certificat sau un cont. Aici trebuie să decideți voi, eu prefer certificatele. Un detaliu delicat legat de drepturi. Ofer drepturi de scriere – nu se va putea face nici măcar „reset config”.
În privința generării, copieri de certificat și importului nu ar trebui să apară probleme:
Pe scurt, lista comenzilorPe PC-ul vostru
ssh-keygen -t RSA, răspundem la întrebări, salvăm cheia.
Copiem pe mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
În prealabil, trebuie să creați un cont și să îi alocați drepturi.
Verificăm conexiunea prin certificat
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Scriem 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
Iată și un exemplu de 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
După cum se vede din configurația de mai sus, constituirea propriilor playbook-uri nu este o sarcină complicată. E suficient să stăpânești bine cli mikrotik. Să presupunem o situație în care pe toate routerele trebuie să eliminăm lista de adrese cu date specifice, atunci:
Găsiți și ștergeți/ip firewal address-list remove [find where list=«gov.ru»]
Am ales să nu includ aici întreaga listă de firewall-uri deoarece aceasta va fi individualizată pentru fiecare proiect. Dar un singur lucru pot să spun cu siguranță, folosiți doar lista de adrese.
În ceea ce privește GITLAB, lucrurile sunt clare. Nu voi insista asupra acestui aspect. Totul este organizat frumos pe sarcini separate, șabloane, manipulatoare.
Powershell
Aici vor fi 3 fișiere. De ce powershell? Instrumentul pentru generarea configurațiilor poate fi oricare, în funcție de preferințele fiecăruia. În acest caz, toți avem Windows pe ПК-uri, așa că de ce să folosim bash, când powershell este mai convenabil. Fiecare cu ce îi este mai ușor.
Scriptul propriu-zis (simplu și clar):[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
Vă rog să mă iertați, nu pot să postez toate regulile deoarece nu ar fi prea frumos. Puteți să vă creați propriile reguli, ghidându-vă după cele mai bune practici.
De exemplu, iată lista de linkuri pe care m-am bazat::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack – trebuie să știți că, o dată activat fasttrack, regulile de prioritizare și shaping al traficului nu vor funcționa - util pentru dispozitive slabe.
Semnificații pentru variabile:Exemplele sunt următoarele rețele:
192.168.0.0/24 rețeaua de lucru
172.22.4.0/24 rețeaua VOIP
10.0.0.0/24 rețeaua pentru clienți fără acces la rețeaua locală
192.168.255.0/24 rețeaua VPN pentru filiale mari
172.19.255.0/24 rețeaua VPN pentru mici
Adresa rețelei constă din 4 numere zecimale, respectiv A.B.C.D; pe același principiu funcționează și înlocuirea, dacă la rulare se cere B, atunci trebuie introdus pentru rețeaua 192.168.0.0/24 numărul 0, iar pentru C = 0.
$EXTERNALIPADDRESS – adresa dedicată de la furnizor.
$EXTERNALIPROUTE – ruta implicită către rețeaua 0.0.0.0/0
$BWorknets – rețeaua de lucru, în exemplul nostru va fi 168
$CWorknets — Rețea de lucru, în exemplul nostru aici va fi 0
$BVoipNets — Rețea VOIP, în exemplul nostru aici 22
$CVoipNets — Rețea VOIP, în exemplul nostru aici 4
$CClientss — Rețea pentru clienți – acces doar la internet, în cazul nostru aici 0
$BVPNWORKs — Rețea VPN pentru filiale mari, în exemplul nostru 20
$CVPNWORKs — Rețea VPN pentru filiale mari, în exemplul nostru 255
$BVPNCLIENTS — Rețea VPN pentru filiale mici, deci 19
$CVPNCLIENTS — Rețea VPN pentru filiale mici, deci 255
$NAMEROUTER — numele routerului
$ServerCertificate — numele certificatului pe care îl importați anterior
$infile — Indicați calea către fișierul din care vom citi configurația, de exemplu D:config.txt (mai bine calea în engleză fără ghilimele și spații)
$outfile — indicați calea unde să salvați, de exemplu D:MT-test.txt
Am modificat intenționat adresele în exemple din motive evidente.
Am omis punctul referitor la detectarea atacurilor și a comportamentului anormal – acest subiect merită un articol separat. Dar este important de menționat că în această categorie pot fi utilizate valorile datelor de monitorizare cu Zabbix + datele obținute din curl cu elasticsearch.
La ce aspecte trebuie să acordați atenție:
- Planul rețelelor. Ar fi mai bine să-l elaborați imediat într-un format ușor de citit. Excel este suficient. Din păcate, foarte des văd rețele întocmite după principiul „A apărut o nouă filiala, iată vă ofer un /24”. Nimeni nu verifică câte dispozitive sunt planificate în acel loc și dacă va exista o creștere ulterioară. De exemplu, a fost deschis un magazin mic, unde se știe că nu vor fi mai mult de 10 dispozitive, de ce să alocați un /24? Pentru filialele mari – dimpotrivă, se alocă un /24, dar numărul dispozitivelor ajunge la 500 — este mai ușor să adăugați o rețea, dar dorim să planificăm totul din timp.
- Reguli de filtrare. Dacă în proiect se preconizează că va fi o separare a rețelelor și o segmentare maximă. Cele mai bune practici se schimbă în timp. În trecut, separăm rețeaua PC-urilor de rețeaua imprimantelor, acum este destul de normal să nu separăm aceste rețele. Merită să folosiți bunul simț și să nu creați o mulțime de subrețele acolo unde nu sunt necesare și să nu le uniți pe toate într-o singură rețea.
- Setările „de aur” pe toate routerele. Adică, dacă v-ați decis asupra planului, ar fi bine să preconizați totul din timp și să încercați să faceți astfel încât toate setările să fie identice - să fie doar liste de adrese și adrese IP diferite. În cazul problemelor, timpul necesar pentru depanare va fi mai mic.
- Aspectele organizaționale sunt la fel de importante ca cele tehnice. Adesea, angajații leneși urmează recomandările date "manual", fără a utiliza configurațiile și scripturile gata pregătite, ceea ce duce în cele din urmă la probleme inutile.
Despre rutare dinamică. A fost folosit OSPF cu divizare pe zone. Dar, fiind un stand de testare, este mai interesant să configurezi astfel de lucruri în condiții reale.
Sper că nimeni nu s-a supărat că nu am publicat configurațiile routerelor. Cred că linkurile sunt suficiente, iar mai departe totul depinde de cerințe. Și desigur teste, trebuie mai multe teste.
Îmi doresc ca toată lumea în noul an să își realizeze proiectele. Fie ca access granted să fie cu voi!!!
Sursa: habr.com
