Cześć wszystkim. Artykuł ten jest skierowany do osób, które mają w swojej sieci wiele urządzeń MikroTik i chcą maksymalnie ujednolicić konfigurację, aby uniknąć podłączania się do każdego urządzenia z osobna. W tym artykule opiszę projekt, który, niestety, nie doszedł do etapu wdrożenia z powodu czynników ludzkich. Krótko mówiąc: ponad 200 routerów, szybka konfiguracja i szkolenie personelu, ujednolicenie według regionów, filtrowanie sieci i określonych hostów, możliwość łatwego dodawania reguł na wszystkie urządzenia, logowanie i kontrola dostępu.
To, co opisano poniżej, nie rości sobie prawa do bycia gotowym przypadkiem, ale mam nadzieję, że przyda się Wam przy planowaniu swoich sieci i minimalizowaniu błędów. Może niektóre punkty i rozwiązania wydają się Wam nie do końca poprawne – jeśli tak, proszę pisać w komentarzach. Krytyka w tym przypadku będzie doświadczeniem, które wzbogaci naszą wspólną wiedzę. Dlatego, drogi czytelniku, zajrzyj w komentarze, być może autor popełnił poważny błąd – społeczność pomoże.
Liczba routerów wynosi 200-300, rozesłanych po różnych miastach z różną jakością połączenia internetowego. Należy wszystko zorganizować estetycznie i w przystępny sposób wyjaśnić lokalnym administratorom, jak to wszystko będzie działać.
Zatem, od czego zaczyna się każdy projekt. Oczywiście od Wymagania.
- Organizacja planu sieci we wszystkich oddziałach zgodnie z wymaganiami klienta, segmentacja sieci (od 3 do 20 sieci w oddziałach w zależności od liczby urządzeń).
- Konfiguracja urządzeń w każdym oddziale. Sprawdzanie rzeczywistej prędkości łącza dostawcy w różnych warunkach pracy.
- Organizacja zabezpieczeń urządzeń, zarządzanie zgodnie z białą listą, automatyczne wykrywanie ataków z automatycznym wpisywaniem do czarnej listy na określony czas, minimalizacja użycia różnych narzędzi technicznych wykorzystywanych do przechwytywania dostępu do zarządzania oraz rezygnacja z obsługi.
- Organizacja bezpiecznych połączeń VPN z filtrowaniem według sieci zgodnie z wymaganiami klienta. Minimum 3 połączenia VPN z każdego oddziału do centrum.
- Na podstawie punktów 1 i 2. Wybór optymalnych ścieżek budowy odpornościowych połączeń VPN. Technologia dynamicznego routingu może być wybrana przez wykonawcę przy właściwym uzasadnieniu.
- Organizacja priorytetyzacji ruchu według protokołów, portów, hostów oraz innych specyficznych usług używanych przez klienta. (VOIP, hosty z ważnymi usługami)
- Organizacja monitorowania i logowania zdarzeń routerów w celu reagowania pracowników wsparcia technicznego.
Jak rozumiemy, w pewnych przypadkach specyfikacja jest tworzona na podstawie wymagań. Te wymagania sformułowałem samodzielnie, wysłuchując głównych problemów. Zakładałem, że wykonaniem tych punktów może zająć się ktoś inny.
Jakie narzędzia będą używane do realizacji tych wymagań:
- Stos ELK (po pewnym czasie zrozumiano, że zamiast logstash będzie używany fluentd).
- Ansible. W celu wygodniejszego zarządzania i podziału dostępu będziemy korzystać z AWX.
- GITLAB. Tu nie ma potrzeby wyjaśniać. Kto mógłby się obejść bez kontroli wersji naszych konfiguracji.
- PowerShell. Będzie prosty skrypt do początkowej generacji konfiguracji.
- Wiki dokumentacyjne do pisania dokumentacji i instrukcji. W tym przypadku korzystamy z habr.com.
- Monitorowanie będzie realizowane przez zabbix. Tam także zostanie narysowany schemat połączeń dla ogólnego zrozumienia.
Zagadnienia związane z konfiguracją EFK
W pierwszym punkcie opiszę tylko ideologię, według której będą budowane indeksy. Istnieje wiele
świetnych artykułów na temat konfiguracji i odbioru logów z urządzeń działających pod kontrolą mikrotik.
Skupię się na niektórych aspektach:
1. Zgodnie ze schematem, należy przemyśleć odbiór logów z różnych miejsc i na różnych portach. W tym celu będziemy używać agregatora logów. Dodatkowo chcemy stworzyć uniwersalne wykresy dla wszystkich routerów z możliwością podziału dostępu. Wówczas indeksy budujemy w następujący sposób:
oto fragment konfiguracji z fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
W ten sposób możemy łączyć routery i segmentować zgodnie z planem - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Po co tak utrudniać? Rozumiemy, że będziemy mieli 200 i więcej urządzeń. Trudno wszystko kontrolować. Od wersji 6.8 elasticsearch nasze ustawienia bezpieczeństwa (bez zakupu licencji) są dostępne, dzięki czemu możemy rozdzielić prawa do przeglądania między pracownikami wsparcia technicznego a lokalnymi administratorami systemów.
Tabele i wykresy - tutaj trzeba po prostu się dogadać - albo korzystać z jednolitych, albo każdy robi tak, jak mu wygodnie.
2. W kwestii logowania. Jeśli w regułach firewall włączamy logi, to nazwy robimy bez spacji. Widać, że korzystając z prostego konfiguratora w fluentd, możemy filtrować dane i tworzyć wygodne panele. Na poniższym obrazku - mój domowy router.
3. W kwestii zajmowanej przestrzeni i logów. Średnio, przy 1000 wiadomościach na godzinę, logi zajmują od 2 do 3 MB dziennie, co, zgadzam się, nie jest dużo. Wersja elasticsearch 7.5.
ANSIBLE.AWX
Na nasze szczęście mamy gotowy moduł dla routeros.
Wskazałem na AWX, ale poniższe komendy dotyczą tylko czystego ansible – myślę, że dla tych, którzy pracowali z ansible, nie będzie problemów z używaniem przez GUI awx.
Szczerze przyznam, że wcześniej oglądałem inne poradniki, w których używano ssh, i wszyscy mieli różne problemy z czasem odpowiedzi i wieloma innymi problemami. Powtarzam, nie doszło to do walki :) traktujcie te informacje jako eksperyment, który nie poszedł dalej niż test z 20 routerami.
Musimy użyć certyfikatu lub konta. Tu decydujecie sami, ja jestem za certyfikatami. Pewien subtelny moment dotyczący uprawnień. Daję prawa na zapis – przynajmniej nie będzie można wykonać „reset config”.
W przypadku generowania, kopiowania certyfikatu i importu nie powinno być żadnych problemów:
Krótkością listy poleceńNa waszym PC
ssh-keygen -t RSA, odpowiadamy na pytania, zapisujemy klucz.
Kopiujemy na mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Najpierw musimy stworzyć konto i nadać mu uprawnienia.
Sprawdzamy połączenie przez certyfikat
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Wpisujemy 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
A oto przykład 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
Jak widać z powyższej konfiguracji, tworzenie własnych playbooków nie jest trudne. Wystarczy dobrze opanować CLI mikrotik. Wyobraźmy sobie sytuację, gdy we wszystkich routerach trzeba usunąć listę adresów z określonymi danymi, wtedy:
Znajdź i usuń/ip firewal address-list remove [find where list=«gov.ru»]
Celowo nie umieściłem tutaj całego opisu zapory, ponieważ będzie on indywidualny dla każdego projektu. Ale mogę jedno powiedzieć na pewno, używaj tylko listy adresów.
W GITLAB wszystko jasne. Nie będę zatrzymywać się na tym punkcie. Wszystko jest uporządkowane według poszczególnych zadań, szablonów, obsługi.
Powershell
Będą tutaj trzy pliki. Dlaczego powershell? Narzędzie do generowania konfiguracji można wybierać dowolnie, w zależności od preferencji. W tym przypadku wszyscy mają Windows na komputerach, więc po co robić w bashu, gdy wygodniej używać powershella. Każdy ma swoje preferencje.
Oto sam skrypt (prosty i zrozumiały):[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
Proszę mnie wybaczyć, nie mogę opublikować wszystkich zasad, ponieważ nie wyglądałoby to zbyt estetycznie. Zasady możesz stworzyć samodzielnie, kierując się najlepszymi praktykami.
Na przykład oto lista linków, którymi się kierowałem::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — tutaj należy wiedzieć, że gdy fasttrack jest włączony, nie będą działać zasady priorytetyzacji i kształtowania ruchu – jest to przydatne dla słabszych urządzeń.
Oznaczenia dotyczące zmiennych:W przykładzie wzięto następujące sieci:
192.168.0.0/24 sieć robocza
172.22.4.0/24 sieć VOIP
10.0.0.0/24 sieć dla klientów bez dostępu do lokalnej sieci
192.168.255.0/24 sieć VPN dla dużych oddziałów
172.19.255.0/24 sieć VPN dla mniejszych
Adres sieci składa się z 4 dziesiętnych cyfr, odpowiednio A.B.C.D, według tej samej zasady odbywa się zamiana, jeśli przy uruchomieniu jest wymagane B, to należy dla sieci 192.168.0.0/24 wpisać numer 0, a dla C = 0.
$EXTERNALIPADDRESS — przydzielony adres od dostawcy.
$EXTERNALIPROUTE — domyślny route dla sieci 0.0.0.0/0
$BWorknets — sieć robocza, w naszym przykładzie będzie to 168
$CWorknets — sieć robocza, w naszym przykładzie będzie to 0
$BVoipNets — sieć VOIP w naszym przykładzie tutaj 22
$CVoipNets — sieć VOIP w naszym przykładzie tutaj 4
$CClientss — sieć dla klientów – dostęp tylko w internecie, w naszym przypadku tutaj 0
$BVPNWORKs — sieć VPN dla dużych oddziałów, w naszym przykładzie 20
$CVPNWORKs — sieć VPN dla dużych oddziałów, w naszym przykładzie 255
$BVPNCLIENTS — sieć VPN dla małych oddziałów, więc 19
$CVPNCLIENTS — sieć VPN dla małych oddziałów, więc 255
$NAMEROUTER — nazwa routera
$ServerCertificate — nazwa certyfikatu, który musisz wcześniej zaimportować
$infile — wskaźnik ścieżki do pliku, z którego będziemy czytać konfigurację, na przykład D:config.txt (lepiej angielska ścieżka bez cudzysłowów i spacji)
$outfile — wskaźnik ścieżki, gdzie zapisać, na przykład D:MT-test.txt
Celowo zmieniłem adresy w przykładach z oczywistych powodów.
Pominąłem punkt dotyczący wykrywania ataków i anomalii – to zasługuje na osobny artykuł. Ale należy zaznaczyć, że w tej kategorii można użyć danych monitoringu z Zabbix + przetworzonych danych curl z elasticsearch.
Na jakich aspektach należy skupić uwagę:
- Plan sieci. Lepiej od razu sporządzić go w czytelnym formacie. W zupełności wystarczy Excel. Niestety, często widzę, że sieci są konstruowane na zasadzie: "Pojawił się nowy oddział, oto wam /24". Nikt nie bada, ile urządzeń planuje się w danym miejscu i czy będzie dalszy wzrost. Na przykład, otwarto mały sklep, w którym od razu wiadomo, że urządzeń będzie nie więcej niż 10, po co przydzielać /24? W przypadku dużych oddziałów – przeciwnie, przydzielają /24, a urządzeń jest 500 — można po prostu dodać sieć, ale warto wszystko przemyśleć z góry.
- Zasady filtrowania. Jeśli projekt przewiduje, że będzie podział sieci i maksymalna segmentacja. Najlepsze praktyki zmieniają się z biegiem czasu. Wcześniej dzielono sieć komputerów i sieć drukarek, teraz całkiem normalne jest, aby tych sieci nie dzielić. Warto używać zdrowego rozsądku i nie rozmnażać wielu podsieci tam, gdzie nie są potrzebne i nie łączyć w jedną sieć wszystkich urządzeń.
- „Złote” ustawienia we wszystkich routerach. Tzn. jeśli już ustaliłeś plan. Warto od razu wszystko przewidzieć i starać się, aby wszystkie ustawienia były identyczne – różniły się tylko listą adresów i adresami IP. W przypadku problemów, czas na rozwiązywanie będzie krótszy.
- Kwestie organizacyjne są równie ważne jak techniczne. Często leniwi pracownicy wykonują podane zalecenia "ręcznie", nie korzystając z gotowych konfiguracji i skryptów, co na końcu prowadzi do problemów bez powodu.
O dynamicznym routingu. Używano OSPF z podziałem na strefy. Ale to przecież testowe środowisko, w realnych warunkach takie rzeczy konfiguruje się znacznie ciekawiej.
Mam nadzieję, że nikt nie jest rozczarowany, że nie podzieliłem się konfiguracjami routerów. Myślę, że wystarczą linki, a dalej wszystko zależy od wymagań. I oczywiście testy, potrzebujemy więcej testów.
Życzę wszystkim w nowym roku zrealizowania swoich projektów. Niech z wami będzie access granted!!!
Źródło: habr.com
