Ciao a tutti. Questo articolo è rivolto a coloro che hanno un gran numero di dispositivi MikroTik e desiderano massimizzare l'unificazione, evitando di collegarsi a ciascun dispositivo singolarmente. In questo articolo descriverò un progetto che, purtroppo, non è arrivato alla fase operativa a causa di fattori umani. In breve: più di 200 router, configurazione veloce e formazione del personale, unificazione per regioni, filtraggio delle reti e di determinati host, possibilità di aggiungere facilmente regole su tutti i dispositivi, registrazione e controllo degli accessi.
Ciò che viene descritto di seguito non pretende di essere un caso concluso, ma spero possa risultare utile per la pianificazione delle proprie reti e la minimizzazione degli errori. Alcuni punti e soluzioni potrebbero sembrare non del tutto corretti – se così fosse, scrivete nei commenti. La critica sarà un contributo all'esperienza collettiva. Quindi, lettore, dai un'occhiata ai commenti, potrebbe essere che l'autore abbia commesso un errore madornale – la comunità aiuterà.
Il numero di router è compreso tra 200 e 300, distribuiti in diverse città con diverse qualità di connessione a Internet. È necessario rendere tutto chiaro e accessibile per spiegare ai locali amministratori di sistema come funzionerà tutto.
Quindi, da dove inizia qualsiasi progetto? Naturalmente, da Requisiti.
- L'organizzazione del piano di rete per tutte le filiali secondo le esigenze del cliente, segmentazione delle reti (da 3 a 20 reti nelle filiali a seconda del numero di dispositivi).
- Configurazione dei dispositivi in ogni filiale. Verifica della reale velocità di trasferimento del provider in diverse condizioni di lavoro.
- Organizzazione della protezione dei dispositivi, gestione tramite lista bianca, autodetenzione degli attacchi con aggiunta automatica nella lista nera per un determinato intervallo di tempo, minimizzazione dell'uso di vari mezzi tecnici impiegati per intercettare il controllo e abbandono della gestione.
- Organizzazione di connessioni VPN sicure con filtraggio delle reti secondo le esigenze del cliente. Almeno 3 connessioni VPN da ogni filiale al centro.
- Sulla base dei punti 1 e 2. Selezionare i percorsi ottimali per costruire VPN ad alta disponibilità. La tecnologia di routing dinamico, con adeguata giustificazione, può essere selezionata dall'esecutore.
- Organizzazione della priorizzazione del traffico in base a protocolli, porte, host e altri servizi specifici utilizzati dal cliente. (VOIP, host con servizi importanti)
- Organizzazione del monitoraggio e registrazione degli eventi dai router per consentire una risposta tempestiva da parte del personale di supporto tecnico.
Come sappiamo, in alcuni casi il capitolato viene redatto a partire dalle esigenze. Queste necessità le ho formulate da solo, ascoltando i principali problemi. Ho considerato la possibilità che l'esecuzione di questi punti potesse essere svolta da qualcun altro.
Quali strumenti verranno utilizzati per soddisfare queste esigenze:
- Stack ELK (dopo un certo tempo, ho realizzato che invece di logstash sarà utilizzato fluentd).
- Ansible. Per facilitare l'amministrazione e la divisione degli accessi utilizzeremo AWX.
- GITLAB. Qui non serve spiegare. Dove possiamo evitare di controllare le versioni delle nostre configurazioni.
- PowerShell. Ci sarà un semplice script per la generazione iniziale della configurazione.
- Doku Wiki, per redigere documentazione e guide. In questo caso, utilizziamo habr.com.
- Il monitoraggio sarà effettuato tramite Zabbix. Anche lì verrà disegnata la mappa delle connessioni per una comprensione generale.
Aspetti della configurazione EFK
Per il primo punto, descriverò solo l'ideologia secondo cui saranno costruiti gli indici. Ci sono molte
ottime articoli sulla configurazione e sul ricevimento dei log dai dispositivi gestiti da MikroTik.
Mi concentrerò su alcuni aspetti:
1. Secondo lo schema, vale la pena pensare alla ricezione dei log da diverse posizioni e su diverse porte. A tal fine, utilizzeremo un aggregatore di log. Inoltre, ci piacerebbe creare grafici universali per tutti i router con possibilità di suddivisione degli accessi. Pertanto, gli indici saranno costruiti nel seguente modo:
questo è un pezzo di configurazione con fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
In questo modo possiamo unire i router e segmentare secondo il piano - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Perché complicarsi così? Comprendiamo che avremo 200 e più dispositivi. Non possiamo seguire tutto. Con la versione 6.8 di Elasticsearch, sono disponibili impostazioni di sicurezza (senza acquisto di licenza), in questo modo possiamo distribuire i diritti di visualizzazione tra il personale del supporto tecnico o amministratori di sistema locali.
Tabelle, grafici – qui bisogna solo accordarsi: si potrebbe utilizzare un formato uniforme, oppure ognuno fa come meglio crede.
2. Sul logging. Se nelle regole del firewall attiviamo il log, i nomi devono essere privi di spazi. Si può notare che, utilizzando una configurazione semplice in fluentd, possiamo filtrare i dati e creare cruscotti utili. Nella foto qui sotto è riportato il mio router domestico.
3. Riguardo allo spazio occupato e ai log. In media, con 1000 messaggi all'ora, i log occupano circa 2-3 MB al giorno, che, ammettiamolo, non è poi molto. Versione elasticsearch 7.5.
ANSIBLE.AWX
Fortunatamente, abbiamo un modulo già pronto per routeros.
Ho menzionato AWX, ma i comandi qui sotto riguardano solo ansible in forma pura – penso che per chi ha già lavorato con ansible non ci saranno problemi ad usarlo attraverso l'interfaccia grafica di awx.
Confesso sinceramente, prima di questo ho guardato altre guide che utilizzavano ssh, e tutti avevano diversi problemi con i tempi di risposta e un sacco di altri problemi. Ripeto, non siamo mai arrivati al combattimento 😊, trattate queste informazioni come un esperimento che non è andato oltre un banco di prova con 20 router.
Dobbiamo usare un certificato o un'utenza. Qui spetta a voi decidere, io preferisco i certificati. Un piccolo dettaglio riguardo ai diritti. Do permessi di scrittura – non sarà possibile neanche eseguire un 'reset config'.
Non dovrebbero esserci problemi con la generazione, copia e importazione del certificato:
In breve, l'elenco dei comandiSulla vostra PC
ssh-keygen -t RSA, rispondere alle domande e salvare la chiave.
Copiare su mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Prima di tutto, è necessario creare un'utenza e assegnarle i diritti.
Verificare la connessione tramite certificato
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Scrivere 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
Ecco un esempio di 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
Come si può vedere dalla configurazione riportata sopra, compilare i propri playbook non è una cosa difficile. Basta avere una buona padronanza del cli mikrotik. Immaginiamo una situazione in cui dobbiamo rimuovere l'address list con dati specifici su tutti i router, quindi:
Trovare e rimuovere/ip firewal address-list remove [find where list=«gov.ru»]
Ho intenzionalmente non incluso qui l'intero elenco delle regole del firewall poiché sarà individuale per ogni progetto. Ma una cosa posso dire con certezza, utilizzate solo l'address list.
Per GITLAB tutto chiaro. Non mi soffermerò su questo punto. Tutto è organizzato bene in task, template, handlers separati.
Powershell
Qui ci saranno 3 file. Perché powershell? È possibile scegliere qualsiasi strumento per generare i config, a chi piace qualsiasi cosa. In questo caso, tutti sui PC hanno Windows, quindi perché usare bash quando powershell è più comodo. A chi piace di più.
Il programma direttamente (semplice e comprensibile):[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
Chiedo scusa, non posso pubblicare tutte le regole poiché non sarebbe molto appropriato. Potete comporre voi stessi le regole, seguendo le migliori pratiche.
Ad esempio, ecco un elenco di link che ho utilizzato come guida::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — qui bisogna sapere che attivando fasttrack non funzioneranno le regole di priorità e shaping del traffico – utile per dispositivi poco potenti.
Simboli per le variabili:Le seguenti reti sono state utilizzate come esempio:
192.168.0.0/24 rete di lavoro
172.22.4.0/24 rete VOIP
10.0.0.0/24 rete per i clienti senza accesso alla rete locale
192.168.255.0/24 rete VPN per grandi filiali
172.19.255.0/24 rete VPN per piccole
L'indirizzo di rete consiste in 4 numeri decimali, rispettivamente A.B.C.D, in base allo stesso principio opera la sostituzione, se durante l'esecuzione richiede B, significa che bisogna inserire per la rete 192.168.0.0/24 il numero 0, e per C = 0.
$EXTERNALIPADDRESS — indirizzo pubblico fornito dal provider.
$EXTERNALIPROUTE — rotta predefinita verso la rete 0.0.0.0/0
$BWorknets — Rete di lavoro, nel nostro esempio qui sarà 168
$CWorknets — Rete di lavoro, nel nostro esempio qui sarà 0
$BVoipNets — Rete VOIP nel nostro esempio qui 22
$CVoipNets — Rete VOIP nel nostro esempio qui 4
$CClientss — Rete per i clienti – accesso solo a internet, nel nostro caso qui 0
$BVPNWORKs — rete VPN per grandi filiali, nel nostro esempio 20
$CVPNWORKs — rete VPN per grandi filiali, nel nostro esempio 255
$BVPNCLIENTS — rete VPN per piccole filiali, quindi 19
$CVPNCLIENTS — rete VPN per piccole filiali, quindi 255
$NAMEROUTER — nome del router
$ServerCertificate — nome del certificato che si importa in precedenza
$infile — Specificare il percorso del file da cui leggeremo la configurazione, ad esempio D:config.txt (meglio un percorso in inglese senza virgolette e spazi)
$outfile — specificare il percorso in cui salvare, ad esempio D:MT-test.txt
Ho intenzionalmente cambiato gli indirizzi negli esempi per motivi ovvi.
Ho saltato la parte sulla rilevazione degli attacchi e del comportamento anomalo – merita un articolo a parte. Ma è opportuno indicare che in questa categoria si possono utilizzare i valori dei dati di monitoraggio di Zabbix + i dati elaborati di curl con Elasticsearch.
A quali aspetti è necessario prestare attenzione:
- Piano delle reti. È meglio elaborarlo subito in un formato leggibile. Excel è più che sufficiente. Sfortunatamente, vedo molto spesso che le reti vengono create secondo il principio «è comparsa una nuova filiale, ecco a voi un /24». Nessuno chiarisce quante sono le apparecchiature previste in quel luogo e se ci sarà un ulteriore sviluppo. Ad esempio, è stato aperto un piccolo negozio, dove è chiaro fin dall'inizio che le apparecchiature non supereranno 10 unità, perché riservare un /24? Per le grandi filiali è l'opposto: si riserva un /24, mentre le apparecchiature diventano 500 — è possibile aggiungere una rete, ma è preferibile pianificare tutto in anticipo.
- Regole di filtraggio. Se nel progetto è previsto che ci sarà una separazione delle reti e una massima segmentazione. Best Practice cambiano nel tempo. In precedenza si separava la rete dei PC e quella delle stampanti, ora è del tutto normale non separare queste reti. È opportuno usare il buon senso e non creare un numero eccessivo di sottoreti dove non sono necessarie e non unire tutte le apparecchiature in un'unica rete.
- Impostazioni ‘golden’ su tutti i router. Cioè, se avete definito il piano. È necessario prevedere tutto immediatamente e cercare di fare in modo che tutte le impostazioni siano identiche, a parte le diverse address list e gli indirizzi IP. In caso di problemi, il tempo per la risoluzione sarà minore.
- Gli aspetti organizzativi sono altrettanto importanti quanto quelli tecnici. Spesso i dipendenti pigri eseguono le raccomandazioni fornite ‘manualmente’, senza utilizzare configurazioni e script già pronti, il che porta a problemi inutili.
Riguardo al routing dinamico. È stato utilizzato OSPF con divisione per zone. Ma si tratta di un banco di prova, in condizioni operative è più interessante configurare tali cose.
Spero che nessuno si sia offeso per il fatto che non ho pubblicato le configurazioni dei router. Penso che i link siano più che sufficienti, e poi tutto dipende dai requisiti. E naturalmente i test, ci sono bisogno di più test.
Auguro a tutti nel nuovo anno di realizzare i propri progetti. Che vi sia access granted!!!
Fonte: habr.com
