Ўсім прывітанне. Дадзены артыкул разлічаны на тых, у каго ў парку знаходзіцца шмат прылад мікратык, і каму хочацца зрабіць максімальную ўніфікацыю, каб не падключацца на кожную прыладу ў асобнасці. У гэтым артыкуле я апішу праект, які, нажаль, не дайшоў да баявых умоў з-за чалавечых фактараў. Сцісла: больш за 200 маршрутызатараў, хуткая настройка і навучанне персаналу, уніфікацыя па рэгіёнах, фільтраванне сетак і пэўных хастоў, магчымасць лёгкага дадання правіл на ўсе прылады, лагіраванне і кантроль доступу.
Тое, што апісана ніжэй, не прэтэндуе на гатовы кейс, але спадзяюся спатрэбіцца вам пры планаванні сваіх сетак і мінімізацыі памылак. Магчыма, некаторыя пункты і рашэнні вам пададуцца не зусім правільнымі - калі так, пішыце ў каментары. Крытыка ў дадзеным выпадку будзе досведам у агульную скарбонку. Таму, чытач, зазірні ў каментары, магчыма, аўтар дапусціў грубую памылку - супольнасць дапаможа.
Колькасць маршрутызатараў 200-300, раскіданыя па розных гарадах з рознай якасцю інтэрнэт злучэння. Неабходна зрабіць усё прыгожа і даступна растлумачыць лакальным адмінам, як будзе ўсё працаваць.
Такім чынам, з чаго пачынаецца любы праект. Вядома ж, з ТЗ.
- Арганізацыя плана сетак па ўсіх філіялах згодна з патрабаваннямі заказчыка, сегментацыя сетак (ад 3 да 20 сетак у філіялах у залежнасці ад колькасці прылад).
- Настройка прылад у кожным філіяле. Праверка рэальнай прапускной хуткасці правайдэра ў розных умовах працы.
- Арганізацыя абароны прылад, кіраванне па белым спісе, аўтадэктаванне нападаў з аўтазанясеннем у чорны спіс на вызначаны прамежак часу, мінімалізацыя выкарыстання розных тэхнічных сродкаў, выкарыстоўваных для перахопу доступу кіравання і адмовы ад абслугоўвання.
- Арганізацыя абароненых vpn злучэнняў з фільтраваннем па сетках згодна з патрабаваннямі заказчыка. Мінімум 3 vpn злучэння з кожнага філіяла да цэнтра.
- На аснове пункта 1, 2. Выбраць аптымальныя шляхі пабудовы абароненай ад збояў vpn. Тэхналогію дынамічнай маршрутызацыі пры карэктным абгрунтаванні можа абраць выканавец.
- Арганізацыя прыярытызацыі трафіку па пратаколах, партах, хастам і іншым спецыфічным сэрвісам якія выкарыстоўвае заказчык. (VOIP, хасты з важнымі сэрвісамі)
- Арганізацыя маніторынгу і лагіравання падзей маршрутызатараў для рэагавання супрацоўнікаў тэхнічнай падтрымкі.
Як мы разумеем, у шэрагу выпадкаў ТЗ складаецца ад патрабаванняў. Гэтыя патрабаванні я сфармуляваў самастойна, выслухаўшы асноўныя праблемы. Дапускаў магчымасць, што выкананнем гэтых пунктаў, можа заняцца нехта іншы.
Якія прылады будуць выкарыстоўвацца для выканання дадзеных патрабаванняў:
- Стэк ELK (праз некаторы час, нетутэйша разуменне, што замест logstash будзе выкарыстоўвацца fluentd).
- Ansible. Для зручнасці адміністравання і падзелу доступу будзем выкарыстоўваць AWX.
- GITLAB. Тут тлумачыць не трэба. Куды без кантролю версій нашых канфігаў.
- PowerShell. Будзе просценькі скрыпт для першапачатковай генерацыі канфіга.
- Доку вікі, для напісання дакументацыі і кіраўніцтваў. У дадзеным выпадку, выкарыстоўваем habr.com.
- Маніторынг будзе здзяйсняцца праз zabbix. Тамсама будзе намаляваная схема падлучэнняў для агульнага разумення.
Моманты наладкі EFK
Па першым пункце апішу толькі ідэалогію, па якой будуць будавацца індэксы. Ёсць шмат
выдатных артыкулаў па наладзе і прыёме логаў з прылад пад кіраваннем mikrotik.
Спынюся на некаторых момантах:
1. Згодна са схемай, варта прадумаць прыём логаў з розных месцаў і па розных партах. Для гэтага мы будзем выкарыстоўваць агрэгатар логаў. А таксама нам жадаецца зрабіць універсальныя графікі для ўсіх маршрутызатараў з магчымасцю падзелу доступу. Тады індэксы будуем наступным чынам:
tвось кавалак канфіга з fluentd тып elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
хастоў : 9200
порт 9200
Такім чынам мы можам аб'яднаць роўтэры і сегментаваць згодна з планам- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Навошта так ускладняць? Мы разумеем, што ў нас будзе 200 і больш прылад. За ўсім не ўсачыць. З 6.8/XNUMX версіі elasticsearch нам даступныя налады бяспекі (без пакупкі ліцэнзіі), тым самым, мы можам размеркаваць правы на прагляд паміж супрацоўнікамі тех.поддержки або лакальнымі сістэмнымі адміністратарамі.
Табліцы, графікі - тут ужо трэба проста дамовіцца - або выкарыстоўваць аднастайныя, або кожны робіць так, як будзе зручна яму.
2. Па лагіраванні. Калі ў правілах firewall уключаем log, то імёны які робіцца без прабелаў. Відаць, што, выкарыстаўшы просты канфіг у fluentd, мы можам фільтраваць дадзеныя і рабіць зручныя панэлі. На малюнку ніжэй - мой хатні роўтэр.
3. Па займаемым месцы і логах. У сярэднім, пры 1000 паведамленняў у гадзіну, логі займаюць па 2-3 мб у суткі, што, пагодзіцеся, не так шмат. Версія elasticsearch 7.5.
ANSIBLE.AWX
Да нашага шчасця ў нас ёсць, гатовы модуль для routeros
Я паказаў пра AWX, але каманды ніжэй толькі пра ansible у чыстым выглядзе – думаю, для тых, хто працаваў з ansible, не ўзнікне праблем з выкарыстаннем праз gui awx.
Прызнаюся сапраўды, да гэтага глядзеў іншыя гайды, дзе выкарыстоўвалі ssh, і ва ўсіх былі розныя праблемы з часам адказу і яшчэ куча іншых праблем. Паўтаруся, да бою не дайшло , успрымайце дадзеную інфармацыю як эксперымент, які не дайшоў далей стэнда з 20 роўтэраў.
Нам неабходна выкарыстоўваць сертыфікат або ўлік. Тут рашаць вам, я за сертыфікаты. Некаторы тонкі момант па правах. Даю правы на write - хаця б "reset config" зрабіць не атрымаецца.
Па генерацыі, капіяванні сертыфіката і імпарту не павінна ўзнікнуць праблем:
Сцісла лістынг камандНа вашым ПК
ssh-keygen -t RSA, які адказваецца на пытанні, захоўваем ключ.
Капіяваны на mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Папярэдне трэба стварыць улік і вылучыць ёй правы.
Правяраем падлучэнне па сертыфікаце
ssh -p 49475 -i /keys/mtx [электронная пошта абаронена]
Прапісваем 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
Ну і прыклад playbook: - name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
задачы:
- name: add Work_sites
routeros_command:
каманды:
- /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
Як відаць з прыведзенай вышэй канфігурацыі, складанне сваіх playbook нескладаная справа. Досыць добра асвоіць cli mikrotik. Прадстаўляльны сітуацыю, калі на ўсіх роўтэрах трэба прыбраць address list з вызначанымі дадзенымі, тады:
Знайсці і выдаліць/ip firewal address-list remove [find where list=«gov.ru»]
Я маю намер не ўставіў сюды ўвесь лістынг файрвала т.к. ён будзе індывідуальны для кожнага праекта. Але адно магу сказаць сапраўды, выкарыстайце толькі address list.
Па GITLAB усё ясна. Ня буду спыняцца на гэтым моманце. Усё прыгожа па асобных tasks, templates, handlers.
Powershell
Тут будуць 3 файліка. Чаму powershell? Інструмент для генерацыі канфігаў можна выбіраць любы, каму што зручней. У дадзеным выпадку ва ўсіх на пк варта windows, таму навошта рабіць на bash, калі зручней powershell. Каму што зручней.
Непасрэдна сам скрыпт (просты і зразумелы):[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
Прашу мяне прабачыць, не магу выкласці ўсе правілы т.к. гэта будзе не зусім прыгожа. Правілы можаце скласці самі, кіруючыся найлепшымі практыкамі.
Напрыклад, вось спіс спасылак па якіх кіраваўся я::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack - тут трэба ведаць, што пры ўключэнні fasttrack не будуць працаваць правілы прыярытэтызацыі і шэйпінгу трафіку - карысна для слабых прылад.
Умоўныя абазначэнні па пераменных:За прыклад узяты наступныя сеткі:
192.168.0.0/24 працоўная сетка
172.22.4.0/24 VOIP сетка
10.0.0.0/24 сетка для кліентаў без доступу да лакальнай сеткі
192.168.255.0/24 VPN сетка для буйных філіялаў
172.19.255.0/24 VPN сетка для дробных
Адрас сеткі складаецца з 4-х дзесятковых лікаў, адпаведна ABCD, па такім жа прынцыпе працуе замена, калі пры запуску запытвае B, то значыць трэба ўвесці для сеткі 192.168.0.0/24 нумар 0, а для C = 0.
$EXTERNALIPADDRESS - выдзелены адрас ад правайдэра.
$EXTERNALIPROUTE – маршрут па змаўчанні на сетку 0.0.0.0/0
$BWorknets – Працоўная сетка, у нашым прыкладзе тут будзе 168
$CWorknets — Працоўная сетка, у нашым прыкладзе тут будзе 0
$BVoipNets — VOIP сетка ў нашым прыкладзе тут 22
$CVoipNets - VOIP сетка ў нашым прыкладзе тут 4
$CClientss - Сетка для кліентаў - доступ толькі ў інтэрнэт, у нашым выпадку тут 0
$BVPNWORKs - VPN сетка для буйных філіялаў, у нашым прыкладзе 20
$CVPNWORKs - VPN сетка для буйных філіялаў, у нашым прыкладзе 255
$BVPNCLIENTS - VPN сетка для дробных філіялаў, значыць 19
$CVPNCLIENTS - VPN сетка для дробных філіялаў, значыць 255
$NAMEROUTER - імя роўтара
$ServerCertificate - імя сертыфіката, які папярэдне імпартуеце
$infile — пазначыць шлях да файла з якога будзем счытваць канфіг, напрыклад D:config.txt (лепш ангельскі шлях без двукоссяў і прабелаў)
$outfile - паказаць шлях, дзе захаваць, напрыклад D:MT-test.txt
Я наўмысна змяніў адрасы ў прыкладах па зразумелых прычынах.
Прапусціў пункт па дэтэктаванні нападаў і анамальным паводзінам - гэта заслугоўвае асобнага артыкула. Але варта паказаць, што ў дадзенай катэгорыі можна выкарыстоўваць значэнні дадзеных маніторынгу з Zabbix + адпрацаваныя дадзеныя curl з elasticsearch.
На якіх момантах неабходна завастрыць увагу:
- План сетак. Лепш скласці адразу ў чытэльным выглядзе. Суцэль годзе excel. Нажаль, вельмі часта бачу, што сеткі складаюцца па прынцыпе «З'явіўся новы філіял, вось вам /24». Ніхто не высвятляе, колькі мяркуецца прылад у дадзеным месцы і ці будзе далейшы рост. Напрыклад, адкрылася невялікая крама, у якім першапачаткова зразумела, што прылада будзе не больш за 10, навошта вылучаць /24? Па вялікіх філіялах - наадварот, вылучаюць / 24, а прылад становіцца 500 - проста дадаць сетку можна, але хочацца ўсё прадумаць адразу.
- Правілы фільтрацыі. Калі па праекце мяркуецца, што будзе падзел сетак і максімальная сегментацыя. Best Practice з часам мяняюцца. Раней дзялілі сетку ПК і сетку друкарак, зараз цалкам нармальна не дзяліць гэтыя сеткі. Варта выкарыстоўваць разумны сэнс і не пладзіць мноства падсетак там, дзе яны не патрэбныя і не аб'ядноўваць у адну сетку ўсе прылады.
- "Залатыя" налады на ўсіх роўтэрах. Г.зн. калі вы вызначыліся з планам. Варта адразу ўсё прадугледзець і паспрабаваць зрабіць так, каб усе налады былі ідэнтычныя; былі толькі розныя address list і ip адрасы. У выпадку ўзнікаючых праблем, час на адладку будзе меншы.
- Арганізацыйныя моманты не менш важныя, чым тэхнічныя. Часта лянівыя супрацоўнікі выконваюць названыя рэкамендацыі "ўручную", не выкарыстоўваючы гатовыя канфігурацыі і скрыпты, што па выніку прыводзіць да праблем на пустым месцы.
Па дынамічнай маршрутызацыі. Выкарыстоўваўся OSPF з занальным дзяленнем. Але ж гэта тэставы стэнд, у баявых умовах такія рэчы настройваць цікавей.
Спадзяюся ніхто не знерваваўся, што я не выклаў канфігурацыі маршрутызатараў. Думаю, што хопіць спасылак, а далей усё залежыць ад патрабаванняў. І, вядома, тэсты, неабходна больш тэстаў.
Жадаю ўсім у новым годзе рэалізаваць свае праекты. Ды прыбудзе з вамі access granted!!!
Крыніца: habr.com