Hej alle. Denne artikel er rettet mod dem, der har mange MikroTik-enheder i deres park, og som ønsker at skabe maksimal standardisering, så man ikke skal tilslutte sig hver enhed individuelt. I denne artikel vil jeg beskrive et projekt, der desværre ikke nåede kampforhold på grund af menneskelige faktorer. Kort sagt: over 200 routere, hurtig opsætning og træning af personale, standardisering efter regioner, filtrering af netværk og bestemte værter, mulighed for nem tilføjelse af regler til alle enheder, logføring og adgangskontrol.
Det, der beskrives nedenfor, gør ikke krav på at være en færdig løsning, men jeg håber, det kan være nyttigt for dig i planlægningen af dine netværk og minimisering af fejl. Måske vil nogle punkter og løsninger virke lidt forkerte – hvis det er tilfældet, skriv gerne en kommentar. Kritik vil i dette tilfælde bidrage til en fælles erfaring. Så, kære læser, kig ind i kommentarerne, måske har forfatteren lavet en grov fejl – fællesskabet vil hjælpe.
Antallet af routere er 200-300, spredt ud over forskellige byer med varierende internetforbindelseskvalitet. Det er vigtigt at gøre alt pænt og tilgængeligt forklare de lokale administratorer, hvordan det hele vil fungere.
Så, hvad starter ethvert projekt med? Selvfølgelig med Kravspecifikation.
- Organisering af netværksplaner for alle afdelinger i henhold til kundens krav, segmentering af netværk (fra 3 til 20 netværk i filialer afhængigt af antallet af enheder).
- Opsætning af enheder i hver filial. Kontrol af den reelle båndbredde fra udbyderen under forskellige arbejdsforhold.
- Organisering af beskyttelse af enheder, administration via hvidliste, automatisk registrering af angreb med automatisk sortering i sort liste i en bestemt tidsperiode, minimering af brugen af forskellige tekniske midler til aflytning af kontroladgang og afvisning af service.
- Organisering af sikre VPN-forbindelser med filtrering af netværk i henhold til kundens krav. Minimum 3 VPN-forbindelser fra hver filial til centret.
- Baseret på punkt 1, 2. Vælg de optimale ruter til opbygning af failover VPN. Teknologi til dynamisk routing kan vælges af udbyderen med en korrekt begrundelse.
- Organisering af trafikprioritering efter protokoller, porte, værter og andre specifikke tjenester, som kunden bruger. (VOIP, værter med vigtige tjenester)
- Organisering af overvågning og logning af begivenheder fra routere for at reagere på teknisk supportpersonale.
Som vi forstår, udarbejdes kravspecifikationen i visse tilfælde ud fra krav. Disse krav har jeg formuleret selv, efter at have lyttet til de primære problemer. Jeg tog højde for muligheden for, at udførelsen af disse punkter kunne blive overdraget til nogen anden.
Hvilke redskaber vil blive brugt til at opfylde disse krav:
- ELK-stakken (efter noget tid blev det klart, at vi i stedet for logstash vil bruge fluentd).
- Ansible. For at lette administrationen og opdele adgangen vil vi bruge AWX.
- GITLAB. Her er der ikke brug for yderligere forklaring. Hvad skulle vi gøre uden versionskontrol af vores konfigurationer.
- PowerShell. Der vil blive lavet et simpelt script til den indledende generation af konfigurationen.
- Doku-wiki til at skrive dokumentation og vejledninger. I dette tilfælde bruger vi habr.com.
- Overvågningen vil blive udført via zabbix. Der vil også blive tegnet et skema for forbindelser for at få en samlet forståelse.
Indstillinger for EFK
For det første punkt vil jeg kun beskrive den ideologi, hvormed indexerne vil blive bygget. Der er mange
fremragende artikler om opsætning og modtagelse af logs fra enheder drevet af mikrotik.
Jeg vil fokusere på nogle punkter:
1. Ifølge skemaet bør vi overveje modtagelse af logs fra forskellige steder og over forskellige porte. Til dette vil vi bruge en logaggregator. Derudover ønsker vi at lave universelle grafer for alle routere med mulighed for adskilt adgang. Så vil vi bygge indexerne som følger:
her er et stykke konfiguration med fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Dermed kan vi samle routerne og segmentere dem i henhold til planen - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Hvorfor gøre det så kompliceret? Vi forstår, at vi vil have 200 og flere enheder. Det er umuligt at holde styr på alt. Fra version 6.8 af elasticsearch er sikkerhedsindstillinger tilgængelige (uden at købe licens), hvilket gør, at vi kan fordele visningsrettighederne mellem medarbejdere i teknisk support eller lokale systemadministratorer.
Tabeller og diagrammer – her skal vi bare blive enige – enten bruge ensartede, eller hver gør, som det er nemmest for dem.
2. Om logning. Hvis vi aktiverer log i firewall-reglerne, skal vi navngive dem uden mellemrum. Det er tydeligt, at ved at bruge en simpel konfiguration i fluentd kan vi filtrere data og lave praktiske dashboards. På billedet nedenfor er min hjemme-router.
3. Om optaget plads og logs. I gennemsnit, ved 1000 beskeder i timen, optager logs omkring 2-3 MB om dagen, hvilket, må jeg sige, ikke er så meget. Version af elasticsearch 7.5.
ANSIBLE.AWX
Til vores lykke har vi et klar-modul til routeros.
Jeg nævnte AWX, men de nedenstående kommandoer handler kun om ansible i sin rene form – jeg tror, at for dem, der har arbejdet med ansible, ikke vil have problemer med at bruge det via gui awx.
Jeg må indrømme, at jeg før har set andre guides, der brugte ssh, og alle havde forskellige problemer med svartider og en masse andre problemer. Jeg gentager, at det ikke kom til kamp, 😊 overvej disse oplysninger som et eksperiment, der ikke kom længere end en test med 20 routere.
Vi skal bruge et certifikat eller en konto. Det er op til dig at beslutte, jeg står for certifikater. En lille fin detalje om rettigheder. Jeg giver rettigheder til write – man kan næppe få ”reset config” gjort.
Der burde ikke være nogen problemer med at generere, kopiere certifikatet og importere:
Kort opstilling af kommandoerPå din PC
ssh-keygen -t RSA, svar på spørgsmålene, gem nøglen.
Kopier til mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Forinden skal du oprette en konto og give den rettigheder.
Tjekker forbindelsen via certifikat
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Vi skriver 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
Og her er et eksempel på et 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
Som det fremgår af ovenstående konfiguration, er det ikke svært at lave sine egne playbooks. Det er nok at mestre cli mikrotik godt. Lad os forestille os en situation, hvor vi skal fjerne address list med bestemte data fra alle routere, så:
Find og slet/ip firewal address-list remove [find where list=«gov.ru»]
Jeg har bevidst ikke indsat hele firewall-listen her, da den vil være individuel for hvert projekt. Men én ting kan jeg helt klart sige: brug kun address list.
Alt er klart med GITLAB. Jeg vil ikke dvæle ved det punkt. Det ser pænt ud med separate tasks, templates, handlers.
Powershell
Der vil være 3 filer her. Hvorfor Powershell? Enhver værktøj til at generere configs kan vælges, hvad der er nemmest for en. I dette tilfælde har alle Windows, så hvorfor lave det i bash, når Powershell er mere praktisk. Hvad der er nemmest for en.
Selve scriptet (enkelt og forståeligt):[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
Jeg beder om undskyldning, jeg kan ikke dele alle reglerne, da det ikke ville se så pænt ud. Du kan selv sammensætte reglerne ved at følge bedste praksis.
For eksempel er her en liste med links, som jeg har fulgt::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — her skal du vide, at når fasttrack er aktiveret, vil prioritets- og shaping-regler ikke fungere – nyttigt til svage enheder.
Konventioner for variabler:Følgende netværk er taget som eksempel:
192.168.0.0/24 arbejdsnetværk
172.22.4.0/24 VOIP-netværk
10.0.0.0/24 netværk for klienter uden adgang til det lokale netværk
192.168.255.0/24 VPN-netværk for store filialer
172.19.255.0/24 VPN-netværk for mindre
Netværksadressen består af 4 decimaler, i henhold til A.B.C.D, på samme måde fungerer udskiftningen, hvis den ved opstart spørger om B, så skal der indtastes for netværket 192.168.0.0/24 nummer 0, og for C = 0.
$EXTERNALIPADDRESS — tildelt adresse fra udbyderen.
$EXTERNALIPROUTE — standardrute til netværket 0.0.0.0/0
$BWorknets — Arbejdsnetværk, i vores eksempel her vil det være 168
$CWorknets — Arbejdsnetværk, i vores eksempel her vil det være 0
$BVoipNets — VOIP-netværk i vores eksempel her 22
$CVoipNets — VOIP-netværk i vores eksempel her 4
$CClientss — Netværk for kunder – adgang kun til internettet, i vores tilfælde her 0
$BVPNWORKs — VPN-netværk for store filialer, i vores eksempel 20
$CVPNWORKs — VPN-netværk for store filialer, i vores eksempel 255
$BVPNCLIENTS — VPN-netværk for små filialer, altså 19
$CVPNCLIENTS — VPN-netværk for små filialer, altså 255
$NAMEROUTER — navnet på routeren
$ServerCertificate — navnet på certifikatet, som du skal importere først
$infile — Angiv stien til filen, som vi vil læse konfigurationen fra, f.eks. D:config.txt (bedre med engelsk sti uden anførselstegn og mellemrum)
$outfile — angiv stien, hvor gemme, f.eks. D:MT-test.txt
Jeg har bevidst ændret adresserne i eksemplerne af åbenlyse grunde.
Jeg sprang punktet om detektion af angreb og unormalt adfærd over – dette fortjener en separat artikel. Men det skal bemærkes, at i denne kategori kan man anvende overvågningsdata fra Zabbix + de behandlede data fra curl med elasticsearch.
Hvilke punkter bør der lægges vægt på:
- Netværksplan. Det hurtigste er at lave det i et læsbart format. Excel vil være tilstrækkeligt. Desværre ser jeg meget ofte, at netværk opbygges efter princippet 'Der er en ny filial, her er jerneleinen /24'. Ingen undersøger, hvor mange enheder der forventes i dette sted og om der vil være fremtidig vækst. For eksempel, hvis en lille butik åbnes, er det klart, at enhederne ikke vil være mere end 10, så hvorfor afsætte en /24? For store filialer er det modsatte tilfældet, man afsætter en /24, mens der bliver 500 enheder — man kan bare tilføje et netværk, men man vil gerne have det hele gennemtænkt fra starten.
- Filtreringsregler. Hvis projektet forudsætter, at der vil være opdeling af netværk og maksimal segmentering. Best Practices ændrer sig over tid. Tidligere delte vi netværket for PC'er og netværket for printere, nu er det helt acceptabelt ikke at adskille disse netværk. Det er vigtigt at bruge sund fornuft og undgå at skabe mange undernet, hvor de ikke er nødvendige og ikke at samle alle enheder i et netværk.
- De 'gyldne' indstillinger på alle routere. Det vil sige, hvis du har besluttet dig for planen. Det er bedst straks at overveje alt og forsøge at gøre, så alle indstillinger er ens — der vil kun være forskellige address lists og ip-adresser. I tilfælde af problemer vil tiden til fejlfinding være kortere.
- Organisatoriske aspekter er lige så vigtige som de tekniske. Ofte udfører dovne medarbejdere de angivne anbefalinger "manuelt" uden at bruge de færdige konfigurationer og scripts, hvilket til slut fører til problemer uden grund.
Om dynamisk routing. OSPF blev brugt med zonering. Men dette er en teststand, i praksis er det mere interessant at konfigurere sådanne ting.
Jeg håber, at ingen er skuffede over, at jeg ikke offentliggjorde routerkonfigurationerne. Jeg tror, at links er tilstrækkelige, og herefter afhænger alt af kravene. Og selvfølgelig testene, vi har brug for flere tests.
Jeg ønsker alle at realisere deres projekter i det nye år. Må access granted være med jer!!!
Kilde: habr.com
