2010 yilda kompaniya 50 ta server va oddiy tarmoq modeli mavjud edi: backend, frontend va xavfsizlik devori. Serverlar soni ko'paydi, model yanada murakkablashdi: bosqichma-bosqich, ACL-li izolyatsiyalangan VLAN-lar, keyin VRF-li VPN-lar, L2-da ACL-li VLAN, L3-da ACL-li VRF. Bosh aylanyaptimi? Keyinchalik qiziqarliroq bo'ladi.
16 000 server mavjud bo'lganda, juda ko'p heterojen segmentlar bilan ko'z yoshlarisiz ishlash imkonsiz bo'lib qoldi. Shunday qilib, biz boshqa yechim topdik. Biz Netfilter stekini oldik, unga ma'lumotlar manbai sifatida konsul qo'shdik va tez tarqatiladigan xavfsizlik devoriga ega bo'ldik. Ular marshrutizatorlardagi ACL-larni almashtirdilar va ularni tashqi va ichki xavfsizlik devori sifatida ishlatishdi. Asbobni dinamik boshqarish uchun biz hamma joyda qo'llanilgan BEFW tizimini ishlab chiqdik: foydalanuvchining mahsulot tarmog'iga kirishini boshqarishdan tarmoq segmentlarini bir-biridan izolyatsiya qilishgacha.
U sizga bularning barchasi qanday ishlashini va nima uchun ushbu tizimni batafsil ko'rib chiqish kerakligini aytib beradi. Ivan Agarkov () kompaniyaning Minskdagi rivojlanish markazining Texnik xizmat ko'rsatish bo'limining infratuzilma xavfsizligi guruhining rahbari. Ivan SELinux muxlisi, Perlni yaxshi ko'radi va kod yozadi. Axborot xavfsizligi guruhi rahbari sifatida u Wargaming-ni xakerlardan himoya qilish va kompaniyadagi barcha o'yin serverlarining ishlashini ta'minlash uchun muntazam ravishda jurnallar, zaxira nusxalar va ilmiy-tadqiqot ishlari bilan ishlaydi.
Tarixiy tarix
Buni qanday qilganimizni aytishdan oldin, men sizga birinchi navbatda qanday qilib kelganimizni va nima uchun kerak bo'lganini aytib beraman. Buning uchun 9 yil orqaga qaytaylik: 2010, World of Tanks endigina paydo bo'ldi. Wargaming-da taxminan 50 ta server mavjud edi.
Kompaniya serverining o'sish jadvali.
Bizda tarmoq modeli bor edi. O'sha vaqt uchun bu optimal edi.
Tarmoq modeli 2010 yil.
Old tomonda bizni buzmoqchi bo'lgan yomon odamlar bor, lekin u xavfsizlik devoriga ega. Backendda xavfsizlik devori yo'q, lekin u erda 50 ta server mavjud, biz ularning barchasini bilamiz. Hammasi yaxshi ishlaydi.
4 yil ichida serverlar parki 100 baravarga o'sdi, ya'ni 5000 taga etdi. Birinchi izolyatsiyalangan tarmoqlar paydo bo'ldi - staging: ular ishlab chiqarishga chiqa olmadilar va ko'pincha u erda xavfli bo'lishi mumkin bo'lgan narsalar ishlaydi.
Tarmoq modeli 2014 yil.
Inertiya bo'yicha biz bir xil apparat qismlaridan foydalandik va barcha ishlar izolyatsiya qilingan VLAN-larda amalga oshirildi: ACLlar VLAN-larga yoziladi, ular qandaydir ulanishga ruxsat beradi yoki rad etadi.
2016-yilda serverlar soni 8000 taga yetdi.Wargaming boshqa studiyalarni oʻziga singdirdi va qoʻshimcha filial tarmoqlari paydo boʻldi. Ular biznikiga o'xshaydi, lekin unchalik emas: VLAN ko'pincha hamkorlar uchun ishlamaydi, siz VRF bilan VPN-dan foydalanishingiz kerak, izolyatsiya yanada murakkablashadi. ACL izolyatsiya aralashmasi o'sdi.
Tarmoq modeli 2016 yil.
2018 yil boshiga kelib mashinalar parki 16 000 taga yetdi. 6 ta segment bor edi, qolganlarini, shu jumladan moliyaviy ma’lumotlar saqlanadigan yopiqlarini hisobga olmadik. Konteyner tarmoqlari (Kubernetes), DevOps, VPN orqali, masalan, IVS dan ulangan bulutli tarmoqlar paydo bo'ldi. Ko'p qoidalar bor edi - bu og'riqli edi.
2018 yilda tarmoq modeli va izolyatsiyalash usullari.
Izolyatsiya uchun biz foydalandik: L2 da ACL bilan VLAN, L3 da ACL bilan VRF, VPN va boshqalar. Juda ko'p.
Muammolar
Har bir inson ACL va VLAN bilan yashaydi. Nima bo'ldi? Bu savolga Garold javob beradi, og'riqni yashiradi.
Ko'p muammolar bor edi, lekin beshta katta muammolar bor edi.
- Yangi qoidalar uchun geometrik narx oshishi. Har bir yangi qoidani qo'shish avvalgisidan ko'ra ko'proq vaqt talab qildi, chunki birinchi navbatda bunday qoida mavjudligini ko'rish kerak edi.
- Segmentlar ichida xavfsizlik devori yo'q. Segmentlar qandaydir tarzda bir-biridan ajratilgan va ichkarida allaqachon resurslar etarli emas edi.
- Qoidalar uzoq vaqt davomida qo'llanilgan. Operatorlar bir soat ichida bitta mahalliy qoidani qo'lda yozishlari mumkin edi. Global bir necha kun davom etdi.
- Audit qoidalari bilan bog'liq qiyinchiliklar. Aniqrog'i, buning iloji yo'q edi. Birinchi qoidalar 2010 yilda yozilgan va ularning aksariyat mualliflari endi kompaniyada ishlamagan.
- Infratuzilma nazoratining past darajasi. Bu asosiy muammo - biz mamlakatimizda nima bo'layotganini yaxshi bilmasdik.
2018 yilda tarmoq muhandisi: "Yana bir oz ACL kerak" degan gapni eshitganida shunday ko'rinish oldi.
Yechimlar
2018 yil boshida bu borada biror narsa qilishga qaror qilindi.
Integratsiyalarning narxi doimiy ravishda o'sib bormoqda. Boshlanish nuqtasi shundaki, yirik ma'lumotlar markazlari izolyatsiyalangan VLAN va ACL-larni qo'llab-quvvatlashni to'xtatdi, chunki qurilmalarda xotira tugaydi.
Yechim: biz inson omilini olib tashladik va maksimal darajada kirishni avtomatlashtirdik.
Yangi qoidalarni qo'llash uzoq vaqt talab etadi. Yechim: qoidalarni qo'llashni tezlashtirish, uni taqsimlangan va parallel qilish. Bu qoidalar minglab tizimlarga rsync yoki SFTPsiz yetkazilishi uchun taqsimlangan tizimni talab qiladi.
Segmentlar ichida xavfsizlik devori yo'q. Segmentlar ichidagi xavfsizlik devori bir tarmoq ichida turli xil xizmatlar paydo bo'lganda bizga kela boshladi. Yechim: xost darajasida xavfsizlik devoridan foydalaning - xostga asoslangan xavfsizlik devori. Deyarli hamma joyda bizda Linux mavjud va hamma joyda iptables bor, bu muammo emas.
Audit qoidalari bilan bog'liq qiyinchiliklar. Yechim: Ko‘rib chiqish va boshqarish uchun barcha qoidalarni bir joyda saqlang, shunda biz hamma narsani tekshira olamiz.
Infratuzilma ustidan nazoratning past darajasi. Yechim: barcha xizmatlar va ular orasidagi kirishlarni inventarizatsiya qiling.
Bu texnik jarayondan ko'ra ko'proq ma'muriy jarayondir. Ba'zan bizda haftada 200-300 ta yangi nashrlar bor, ayniqsa aksiyalar va bayramlarda. Bundan tashqari, bu bizning DevOps-ning faqat bitta jamoasi uchun. Juda ko'p relizlar bilan qanday portlar, IP-lar va integratsiyalarga ehtiyoj borligini ko'rishning iloji yo'q. Shuning uchun bizga maxsus o'qitilgan xizmat menejerlari kerak edi, ular jamoalarga: "Bu erda nima bor va nima uchun uni ko'tardingiz?"
Biz boshlagan hamma narsadan so'ng, 2019 yilda tarmoq muhandisi shunday ko'rinishni boshladi.
Konsul
Biz xizmat menejerlari yordamida topilgan hamma narsani Konsulga qo'yishga qaror qildik va u erdan iptables qoidalarini yozamiz.
Qanday qilib biz buni qilishga qaror qildik?
- Biz barcha xizmatlar, tarmoqlar va foydalanuvchilarni yig'amiz.
- Keling, ular asosida iptables qoidalarini yarataylik.
- Biz boshqaruvni avtomatlashtiramiz.
- ....
- FOYDA.
Konsul masofaviy API emas, u har bir tugunda ishlashi va iptables-ga yozishi mumkin. Faqat keraksiz narsalarni tozalaydigan avtomatik boshqaruvlarni o'ylab topish qoladi va muammolarning aksariyati hal qilinadi! Qolganini borar ekanmiz.
Nega konsul?
O'zini yaxshi isbotladi. 2014-15 yillarda biz undan parollarni saqlaydigan Vault uchun backend sifatida foydalanganmiz.
Ma'lumotlarni yo'qotmaydi. Foydalanish vaqtida konsul bitta baxtsiz hodisa paytida ma'lumotlarni yo'qotmadi. Bu xavfsizlik devorini boshqarish tizimi uchun katta ortiqcha.
P2P ulanishlari o'zgarishlarning tarqalishini tezlashtiradi. P2P bilan barcha o'zgarishlar tezda amalga oshiriladi, soatlab kutishning hojati yo'q.
Qulay REST API. Biz Apache ZooKeeper-ni ham ko'rib chiqdik, lekin u REST API-ga ega emas, shuning uchun siz qo'ltiq tayoqchalarini o'rnatishingiz kerak bo'ladi.
Ham Key Vault (KV), ham katalog (Xizmat kashfiyoti) sifatida ishlaydi.. Siz bir vaqtning o'zida xizmatlar, kataloglar va ma'lumotlar markazlarini saqlashingiz mumkin. Bu nafaqat biz uchun, balki qo‘shni jamoalar uchun ham qulay, chunki global servisni qurishda biz katta o‘ylaymiz.
Wargaming stekining bir qismi bo'lgan Go'da yozilgan. Biz bu tilni yaxshi ko'ramiz, bizda ko'plab Go dasturchilari bor.
Kuchli ACL tizimi. Konsulda siz kim nima yozishini nazorat qilish uchun ACL dan foydalanishingiz mumkin. Biz xavfsizlik devori qoidalari boshqa hech narsa bilan bir-biriga mos kelmasligiga kafolat beramiz va bu bilan bizda muammolar bo'lmaydi.
Lekin konsulning ham kamchiliklari bor.
- Agar sizda biznes versiyasi bo'lmasa, ma'lumotlar markazida kengaymaydi. U faqat federatsiya tomonidan kengaytirilishi mumkin.
- Tarmoq sifati va server yukiga juda bog'liq. Agar tarmoqda kechikishlar, masalan, notekis tezlik bo'lsa, konsul band serverda server sifatida to'g'ri ishlamaydi. Bu P2P ulanishlari va tarqatish modellarini yangilash bilan bog'liq.
- Mavjudlikni nazorat qilish qiyinligi. Konsul maqomida u hamma narsa yaxshi deb aytishi mumkin, lekin u uzoq vaqt oldin vafot etgan.
Biz ushbu muammolarning aksariyatini Konsuldan foydalanganda hal qildik, shuning uchun uni tanladik. Kompaniyaning muqobil backend rejalari bor, lekin biz muammolarni hal qilishni o'rgandik va hozirda konsul bilan yashayapmiz.
Konsul qanday ishlaydi
Shartli ma'lumotlar markazida uch-beshta serverni o'rnatamiz. Bitta yoki ikkita server ishlamaydi: ular kvorum tashkil qila olmaydi va ma'lumotlar mos kelmasa, kim haq va kim noto'g'ri ekanligini hal qila olmaydi. Beshdan ortiq ma'no yo'q, hosildorlik pasayadi.
Mijozlar serverlarga istalgan tartibda ulanadi: bir xil agentlar, faqat bayroq bilan server = false.
Shundan so'ng, mijozlar P2P ulanishlar ro'yxatini oladilar va o'zaro aloqalarni o'rnatadilar.
Global darajada biz bir nechta ma'lumotlar markazlarini ulaymiz. Shuningdek, ular P2P ni ulashadi va muloqot qilishadi.
Boshqa ma'lumotlar markazidan ma'lumotlarni olishni istasak, so'rov serverdan serverga o'tadi. Ushbu sxema deyiladi Serf protokoli. Serf protokoli, Konsul kabi, HashiCorp tomonidan ishlab chiqilgan.
Konsul haqida ba'zi muhim faktlar
Konsulda uning qanday ishlashini tavsiflovchi hujjatlar bor. Men faqat bilishga arziydigan tanlangan faktlarni beraman.
Konsul serverlari saylovchilar orasidan usta tanlaydi. Konsul har bir maʼlumot markazi uchun serverlar roʻyxatidan master tanlaydi va barcha soʻrovlar serverlar sonidan qatʼi nazar, faqat unga boradi. Magistrni muzlatish qayta saylanishga olib kelmaydi. Agar usta tanlanmagan bo'lsa, so'rovlarga hech kim xizmat ko'rsatmaydi.
Gorizontal masshtabni xohladingizmi? Kechirasiz, yo'q.
Boshqa ma'lumotlar markaziga so'rov qaysi serverga kelganidan qat'i nazar, masterdan masterga o'tadi. Tanlangan usta yukning 100% ni oladi, oldingi so'rovlar bo'yicha yuk bundan mustasno. Ma'lumotlar markazidagi barcha serverlar ma'lumotlarning yangilangan nusxasiga ega, ammo faqat bittasi javob beradi.
Masshtabni o'lchashning yagona usuli - mijozda eskirgan rejimni yoqish.
Eski rejimda siz kvorumsiz javob berishingiz mumkin. Bu biz ma'lumotlar izchilligidan voz kechadigan rejim, lekin odatdagidan biroz tezroq o'qiymiz va har qanday server javob beradi. Tabiiyki, faqat usta orqali yozib olish.
Konsul ma'lumotlar markazlari o'rtasida ma'lumotlarni ko'chirmaydi. Federatsiya yig'ilganda, har bir server faqat o'z ma'lumotlariga ega bo'ladi. Boshqalar uchun u har doim boshqasiga murojaat qiladi.
Tranzaktsiyadan tashqari operatsiyalarning atomligi kafolatlanmaydi. Yodingizda bo'lsin, narsalarni o'zgartira oladigan yagona siz emassiz. Agar siz boshqacha qilishni istasangiz, qulf bilan operatsiyani bajaring.
Bloklash operatsiyalari qulflashni kafolatlamaydi. So'rov to'g'ridan-to'g'ri emas, balki masterdan masterga o'tadi, shuning uchun siz blokirovka qilganingizda, masalan, boshqa ma'lumotlar markazida blokirovka ishlashiga kafolat yo'q.
ACL ham kirishni kafolatlamaydi (ko'p hollarda). ACL ishlamasligi mumkin, chunki u bitta federatsiya ma'lumotlar markazida - ACL ma'lumotlar markazida (Birlamchi DC) saqlanadi. Agar DC sizga javob bermasa, ACL ishlamaydi.
Bitta muzlatilgan usta butun federatsiyaning muzlashiga olib keladi. Misol uchun, federatsiyada 10 ta ma'lumot markazlari mavjud va bittasida tarmoq yomon, bitta master ishlamay qoladi. U bilan muloqot qilgan har bir kishi aylanaga yopishib qoladi: so'rov bor, unga javob yo'q, ip qotib qoladi. Bu qachon sodir bo'lishini bilishning iloji yo'q, bir-ikki soat ichida butun federatsiya quladi. Bu haqda hech narsa qila olmaysiz.
Maqom, kvorum va saylovlar alohida mavzu tomonidan ko'rib chiqiladi. Qayta saylov bo'lmaydi, status hech narsani ko'rsatmaydi. Siz tirik Konsulingiz bor deb o'ylaysiz, so'raysiz va hech narsa bo'lmaydi - javob yo'q. Shu bilan birga, status hamma narsa yaxshi ekanligini ko'rsatadi.
Biz bu muammoga duch keldik va uni oldini olish uchun maʼlumotlar markazlarining alohida qismlarini qayta qurishga majbur boʻldik.
Konsul korxonasining biznes versiyasida yuqoridagi ba'zi kamchiliklar mavjud emas. U juda ko'p foydali funktsiyalarga ega: saylovchilarni tanlash, taqsimlash, masshtablash. Faqat bitta "lekin" bor - taqsimlangan tizim uchun litsenziyalash tizimi juda qimmat.
Hayotdan chiqish: rm -rf /var/lib/consul - agentning barcha kasalliklari uchun davo. Agar biror narsa sizga mos kelmasa, shunchaki ma'lumotlarni o'chirib tashlang va ma'lumotlarni nusxasidan yuklab oling. Katta ehtimol bilan konsul ishlaydi.
BEFW
Keling, Konsulga nima qo'shganimiz haqida gapiraylik.
ning qisqartmasi hisoblanadi BACKEndFireWhammasi. Men omborni yaratganimda, birinchi sinov majburiyatlarini qo'yish uchun mahsulotni qandaydir tarzda nomlashim kerak edi. Bu nom qoladi.
Qoidalar shablonlari
Qoidalar iptables sintaksisida yozilgan.
- -N BEFW
- -P KIRISH TO'CHIRISH
- -A INPUT -m holati-holat BAĞLANTILI, O'RNATISH -j QABUL ET
- -A INPUT -i lo -j QABUL
- -A KIRISH -j BEFW
Hamma narsa BEFW zanjiriga kiradi, bundan mustasno ESTABLISHED, RELATED va localhost. Shablon har qanday bo'lishi mumkin, bu faqat bir misol.
BEFW qanday foydali?
xizmatlar
Bizda xizmat bor, uning har doim porti, ishlaydigan tugunlari bor. Tugunimizdan biz mahalliy agentdan so'rashimiz va qandaydir xizmatimiz borligini bilib olishimiz mumkin. Siz teglarni ham qo'yishingiz mumkin.
Konsulda ishlayotgan va ro'yxatdan o'tgan har qanday xizmat iptables qoidasiga aylanadi. Bizda SSH bor - ochiq port 22. Bash skripti oddiy: curl va iptables, boshqa hech narsa kerak emas.
Mijozlar
Qanday qilib hamma uchun emas, balki tanlab kirishni ochish mumkin? IP ro'yxatlarini xizmat nomi bo'yicha KV xotirasiga qo'shing.
Misol uchun, biz o'ninchi tarmoqdagi hamma SSH_TCP_22 xizmatiga kirish imkoniyatiga ega bo'lishini xohlaymiz. Bitta kichik TTL maydoni qo'shilsinmi? va endi bizda vaqtinchalik ruxsatnomalar bor, masalan, bir kun uchun.
Kirishlar
Biz xizmatlar va mijozlarni bog'laymiz: bizda xizmat bor, KV saqlash har biriga tayyor. Endi biz hammaga emas, balki tanlab kirish imkoniyatini beramiz.
Guruhlar
Har safar kirish uchun minglab IP yozsak, biz charchaymiz. Keling, guruhlarni o'ylab ko'raylik - KVda alohida kichik to'plam. Keling, uni taxallus (yoki guruhlar) deb ataymiz va u erda guruhlarni xuddi shu printsip bo'yicha saqlaymiz.
Ulanamiz: endi biz SSHni P2P uchun emas, balki butun guruh yoki bir nechta guruhlar uchun ochishimiz mumkin. Xuddi shu tarzda, TTL mavjud - siz guruhga qo'shishingiz va guruhdan vaqtincha olib tashlashingiz mumkin.
Integratsiya
Bizning muammomiz - inson omili va avtomatlashtirish. Hozircha biz buni shu tarzda hal qildik.
Biz Puppet bilan ishlaymiz va tizimga tegishli hamma narsani (ilova kodi) ularga o'tkazamiz. Puppetdb (muntazam PostgreSQL) u erda ishlayotgan xizmatlar ro'yxatini saqlaydi, ularni manba turi bo'yicha topish mumkin. U erda kim qayerga murojaat qilayotganini bilib olishingiz mumkin. Buning uchun bizda tortishish so'rovi va birlashtirish so'rovi tizimi mavjud.
Biz befw-sync yozdik, bu ma'lumotlarni uzatishga yordam beradigan oddiy echim. Birinchidan, sinxronlash cookie-fayllariga puppetdb orqali kirish mumkin. U erda HTTP API sozlangan: bizda qanday xizmatlar bor, nima qilish kerakligini so'raymiz. Keyin ular konsulga murojaat qilishadi.
Integratsiya bormi? Ha: ular qoidalarni yozdilar va Pull so'rovlarini qabul qilishga ruxsat berdilar. Sizga ma'lum bir port kerakmi yoki biron bir guruhga xost qo'shing? So'rovni tortib oling, ko'rib chiqing - endi "200 ta boshqa ACL toping va bu haqda biror narsa qilishga harakat qiling."
Optimallashtirish
Bo'sh qoidalar zanjiri bilan localhost-ga ping yuborish 0,075 milodiy vaqtni oladi.
Keling, ushbu zanjirga 10 000 ta iptables manzilini qo'shamiz. Natijada, ping 5 barobar ortadi: iptables to'liq chiziqli, har bir manzilni qayta ishlash biroz vaqt talab etadi.
Minglab ACLlarni ko'chiradigan xavfsizlik devori uchun bizda juda ko'p qoidalar mavjud va bu kechikishni keltirib chiqaradi. Bu o'yin protokollari uchun yomon.
Ammo qo'ysak Ipsetda 10 000 ta manzil Ping hatto kamayadi.
Gap shundaki, ipset uchun "O" (algoritm murakkabligi) qancha qoidalar bo'lishidan qat'i nazar, har doim 1 ga teng. To'g'ri, cheklov bor - 65535 dan ortiq qoidalar bo'lishi mumkin emas. Hozircha biz shu bilan yashaymiz: siz ularni birlashtira olasiz, kengaytirasiz, ikkita ipsetni bittasida qilishingiz mumkin.
saqlash
Iteratsiya jarayonining mantiqiy davomi ipset-da xizmat uchun mijozlar haqidagi ma'lumotlarni saqlashdir.
Endi bizda bir xil SSH bor va biz bir vaqtning o'zida 100 ta IP yozmaymiz, lekin biz muloqot qilishimiz kerak bo'lgan ipset nomini va quyidagi qoidani o'rnatamiz. DROP. Uni bitta qoidaga aylantirish mumkin "Kim bu erda yo'q, DROP", lekin bu aniqroq.
Endi bizda qoidalar va to'plamlar mavjud. Asosiy vazifa - qoidani yozishdan oldin to'plamni yaratish, chunki aks holda iptables qoidani yozmaydi.
Bosh sxema
Diagramma shaklida men aytgan hamma narsa shunday ko'rinadi.
Biz Qo'g'irchoqqa majburiyat beramiz, hamma narsa xostga yuboriladi, bu erda xizmatlar, u erda ipset va u erda ro'yxatdan o'tmaganlarga ruxsat berilmaydi.
Ruxsat berish va rad etish
Dunyoni tezda qutqarish yoki kimnidir tezda o'chirish uchun barcha zanjirlarning boshida biz ikkita ipset qildik: rules_allow и rules_deny. U qanday ishlaydi?
Misol uchun, kimdir bizning veb-saytimizda botlar bilan yuk yaratmoqda. Ilgari siz uning IP-ni jurnallardan topishingiz, tarmoq muhandislariga olib borishingiz kerak edi, shunda ular trafik manbasini topib, uni taqiqlashlari mumkin edi. Endi u boshqacha ko'rinadi.
Biz uni konsulga jo'natamiz, 2,5 soniya kutamiz va u tugadi. Konsul P2P orqali tezda tarqatilganligi sababli, u hamma joyda, dunyoning istalgan burchagida ishlaydi.
Bir marta xavfsizlik devoridagi xato tufayli WOTni qandaydir tarzda to'xtatdim. rules_allow - bu bizning bunday holatlardan sug'urtamiz. Agar biror joyda xavfsizlik devori bilan xato qilgan bo'lsak, biror joyda biror narsa bloklangan bo'lsa, biz har doim shartli yuborishimiz mumkin 0.0/0hamma narsani tezda olish uchun. Keyinchalik biz hamma narsani qo'l bilan tuzatamiz.
Boshqa to'plamlar
Kosmosga boshqa to'plamlarni qo'shishingiz mumkin $IPSETS$.
Nima uchun? Ba'zan kimgadir ipset kerak, masalan, klasterning ba'zi bir qismini o'chirishga taqlid qilish. Har kim har qanday to'plamni olib kelishi mumkin, ularni nomlashi mumkin va ular konsuldan olinadi. Shu bilan birga, to'plamlar iptables qoidalarida qatnashishi yoki jamoa sifatida harakat qilishi mumkin NOOP: Muvofiqlik demon tomonidan saqlanadi.
foydalanuvchilar
Ilgari bu shunday edi: foydalanuvchi tarmoqqa ulangan va domen orqali parametrlarni olgan. Yangi avlod xavfsizlik devorlari paydo bo'lishidan oldin Cisco foydalanuvchining qaerdaligini va IP qaerdaligini qanday tushunishni bilmas edi. Shuning uchun kirish faqat kompyuterning xost nomi orqali berilgan.
Biz nima qildik? Manzilni olganimizda tiqilib qoldik. Odatda bu dot1x, Wi-Fi yoki VPN - hamma narsa RADIUS orqali o'tadi. Har bir foydalanuvchi uchun biz foydalanuvchi nomi bo'yicha guruh yaratamiz va unga dhcp.lease ga teng bo'lgan TTL bilan IP joylashtiramiz - uning amal qilish muddati tugashi bilan qoida yo'qoladi.
Endi biz boshqa guruhlar kabi xizmatlarga foydalanuvchi nomi bilan kirishni ochishimiz mumkin. Xost nomlari o‘zgarganda biz og‘riqdan xalos bo‘ldik va tarmoq muhandislaridan yukni olib tashladik, chunki ularga Cisco endi kerak emas. Endi muhandislarning o'zlari o'z serverlarida kirishni ro'yxatdan o'tkazadilar.
Izolyatsiya
Shu bilan birga, biz izolyatsiyani demontaj qilishni boshladik. Xizmat menejerlari inventarizatsiya qilishdi va biz barcha tarmoqlarimizni tahlil qildik. Keling, ularni bir xil guruhlarga ajratamiz va kerakli serverlarda guruhlar, masalan, rad etish uchun qo'shilgan. Endi bir xil bosqichli izolyatsiya ishlab chiqarishning qoidalarini_ rad etishda tugaydi, lekin ishlab chiqarishning o'zida emas.
Sxema tez va sodda ishlaydi: biz serverlardan barcha ACLlarni olib tashlaymiz, apparatni tushiramiz va izolyatsiya qilingan VLAN sonini kamaytiramiz.
Butunlikni nazorat qilish
Ilgari bizda kimdir xavfsizlik devori qoidasini qo'lda o'zgartirganda xabar beradigan maxsus tetikga ega edik. Men xavfsizlik devori qoidalarini tekshirish uchun katta linter yozayotgan edim, bu qiyin edi. Butunlik endi BEFW tomonidan nazorat qilinadi. U o'zi tuzgan qoidalar o'zgarmasligini g'ayrat bilan ta'minlaydi. Agar kimdir xavfsizlik devori qoidalarini o'zgartirsa, u hamma narsani o'zgartiradi. “Men uydan turib ishlashim uchun tezda proksi-serverni oʻrnatdim” — boshqa bunday variantlar yoʻq.
BEFW xizmatlardan ipsetni va befw.conf ro'yxatini, BEFW zanjiridagi xizmatlar qoidalarini boshqaradi. Lekin u boshqa zanjirlar va qoidalar va boshqa ipsetlarni kuzatmaydi.
Avariyadan himoya qilish
BEFW har doim oxirgi ma'lum bo'lgan yaxshi holatni bevosita state.bin binar tuzilishida saqlaydi. Agar biror narsa noto'g'ri bo'lsa, u har doim shu holatga qaytadi.bin.
Bu konsulning beqaror operatsiyasidan sug'urta, agar u ma'lumot yubormasa yoki kimdir xatoga yo'l qo'ygan va qo'llash mumkin bo'lmagan qoidalarni ishlatgan. Xavfsizlik devorisiz qolmasligimiz uchun, agar biron bir bosqichda xatolik yuzaga kelsa, BEFW oxirgi holatga qaytadi.
Muhim vaziyatlarda bu bizda ishlaydigan xavfsizlik devori qolishi kafolatidir. Admin kelib tuzatadi degan umidda barcha kulrang tarmoqlarni ochamiz. Bir kuni men buni konfiguratsiyaga qo'yaman, lekin hozir bizda uchta kulrang tarmoq mavjud: 10/8, 172/12 va 192.168/16. Konsulimiz ichida bu bizni yanada rivojlantirishga yordam beradigan muhim xususiyatdir.
Namoyish: hisobot davomida Ivan BEFW ning demo rejimini namoyish etadi. Namoyishni tomosha qilish osonroq . Demo manba kodi mavjud .
makr
Men sizga biz duch kelgan xatolar haqida aytib beraman.
ipset add set 0.0.0.0/0. Agar ipset-ga 0.0.0.0/0 qo'shsangiz nima bo'ladi? Barcha IP qo'shiladimi? Internetga kirish imkoniyati mavjudmi?
Yo'q, biz ikki soatlik ishlamay qolgan xatoga duch kelamiz. Bundan tashqari, xato 2016 yildan beri ishlamayapti, u RedHat Bugzilla-da №1297092 raqami ostida joylashgan va biz uni tasodifan topdik - ishlab chiquvchining hisobotidan.
Endi bu BEFWda qat'iy qoida 0.0.0.0/0 ikkita manzilga aylanadi: 0.0.0.0/1 и 128.0.0.0/1.
ipset tiklash to'plami < fayl. Ipset siz aytsangiz nima qiladi restore? Sizningcha, u iptables bilan bir xil ishlaydi? U ma'lumotlarni tiklaydimi?
Bunga o'xshash narsa yo'q - u birlashadi va eski manzillar hech qaerga ketmaydi, siz kirishni bloklamaysiz.
Izolyatsiyani sinab ko'rishda xatolik aniqlandi. Endi juda murakkab tizim mavjud - o'rniga restore amalga oshiriladi create temp, keyin restore flush temp и restore temp. Swap oxirida: atomiklik uchun, chunki agar siz buni birinchi bo'lib qilsangiz flush va bu vaqtda ba'zi paketlar keladi, u tashlab yuboriladi va nimadir noto'g'ri bo'ladi. Demak, u yerda biroz qora sehr bor.
konsul kv get -datacenter=boshqa. Aytganimdek, biz ba'zi ma'lumotlarni so'rayapmiz deb o'ylaymiz, lekin biz ma'lumotlarni olamiz yoki xatoga yo'l qo'yamiz. Biz buni mahalliy konsul orqali qilishimiz mumkin, ammo bu holda ikkalasi ham muzlab qoladi.
Mahalliy konsul mijozi HTTP API orqali o'ralgan. Lekin u shunchaki osilib turadi va Ctrl+C, Ctrl+Z yoki boshqa tugmalarga javob bermaydi, faqat kill -9 keyingi konsolda. Biz katta klaster qurayotganimizda bunga duch keldik. Ammo bizda hali yechim yo'q; biz konsulda bu xatoni tuzatishga tayyormiz.
Konsul rahbari javob bermayapti. Ma'lumotlar markazidagi ustamiz javob bermayapti, biz shunday deb o'ylaymiz: "Ehtimol, qayta tanlash algoritmi hozir ishlaydi?"
Yo'q, bu ishlamaydi va monitoring hech narsani ko'rsatmaydi: konsul majburiyat indeksi borligini, rahbar topilganini, hammasi joyida ekanligini aytadi.
Bu bilan qanday kurashamiz? service consul restart har soatda cronda. Agar sizda 50 ta server bo'lsa, unchalik muhim emas. Ulardan 16 000 tasi bo'lganda, uning qanday ishlashini tushunasiz.
xulosa
Natijada biz quyidagi afzalliklarga ega bo'ldik:
- Barcha Linux mashinalarining 100% qamrovi.
- Tezlik.
- Avtomatlashtirish.
- Biz apparat va tarmoq muhandislarini qullikdan ozod qildik.
- Deyarli cheksiz integratsiya imkoniyatlari paydo bo'ldi: hatto Kubernetes bilan, hatto Ansible bilan, hatto Python bilan ham.
Minusy: Konsul, biz hozir yashashimiz kerak bo'lgan va xatoning juda yuqori narxi. Misol tariqasida, bir marta soat 6:XNUMX da (Rossiyada asosiy vaqt) men tarmoqlar ro'yxatida biror narsani tahrir qilardim. Biz o'sha paytda BEFWda izolyatsiyani qurayotgan edik. Men biror joyda xatoga yo'l qo'ydim, men noto'g'ri niqobni ko'rsatganga o'xshayman, lekin hamma narsa ikki soniya ichida tushib ketdi. Monitoring yonadi, navbatchi yordamchi yugurib keladi: "Bizda hamma narsa bor!" Bo'lim boshlig'i biznesga nima sababdan bu sodir bo'lganini tushuntirganda kul rangga aylandi.
Xatoning narxi shunchalik yuqoriki, biz o'zimizning murakkab oldini olish tartibimizni o'ylab topdik. Agar siz buni yirik ishlab chiqarish maydonchasida amalga oshirsangiz, har kimga Konsul ustidan master token berishingiz shart emas. Bu yomon tugaydi.
Qiymati. Men faqat 400 soat kod yozdim. Mening 4 kishidan iborat jamoam har oyda 10 soat vaqtini hammani qo'llab-quvvatlashga sarflaydi. Har qanday yangi avlod xavfsizlik devori narxi bilan taqqoslaganda, u bepul.
Rejalar. Uzoq muddatli reja konsulni almashtirish yoki to'ldirish uchun muqobil transportni topishdan iborat. Ehtimol, bu Kafka yoki shunga o'xshash narsa bo'ladi. Ammo keyingi yillarda biz Konsulda yashaymiz.
Tezkor rejalar: Fail2ban bilan, monitoring bilan, nftables bilan, ehtimol boshqa tarqatishlar, o'lchovlar, ilg'or monitoring, optimallashtirish bilan integratsiya. Kubernetes qo'llab-quvvatlashi ham rejalarning bir joyida, chunki endi bizda bir nechta klasterlar va istaklar mavjud.
Rejalardan ko'proq:
- trafikdagi anomaliyalarni qidirish;
- tarmoq xaritalarini boshqarish;
- Kubernetes qo'llab-quvvatlash;
- barcha tizimlar uchun paketlarni yig'ish;
- Web-UI.
Biz doimiy ravishda konfiguratsiyani kengaytirish, ko'rsatkichlarni oshirish va optimallashtirish ustida ishlayapmiz.
Loyihaga qo'shiling. Loyiha ajoyib bo'lib chiqdi, lekin, afsuski, bu hali ham bir kishilik loyiha. Kelmoq va biror narsa qilishga harakat qiling: topshiring, sinab ko'ring, biror narsani taklif qiling, baho bering.
Ayni paytda biz tayyorgarlik ko'rmoqdamiz , Sankt-Peterburgda 6 va 7 aprel kunlari bo'lib o'tadi va biz yuqori yuklangan tizimlarni ishlab chiquvchilarni taklif qilamiz. . Tajribali ma'ruzachilar allaqachon nima qilishni bilishadi, ammo yangi gapiradiganlar uchun hech bo'lmaganda tavsiya qilamiz . Konferensiyada ma’ruzachi sifatida ishtirok etish bir qator afzalliklarga ega. Qaysi birini, masalan, oxirida o'qishingiz mumkin .
Manba: www.habr.com