Noong 2010 ang kumpanya mayroong 50 server at isang simpleng modelo ng network: backend, frontend at firewall. Ang bilang ng mga server ay lumago, ang modelo ay naging mas kumplikado: pagtatanghal, nakahiwalay na mga VLAN na may mga ACL, pagkatapos ay mga VPN na may mga VRF, mga VLAN na may mga ACL sa L2, mga VRF na may mga ACL sa L3. Umiikot ang ulo? Mas magiging masaya mamaya.
Noong mayroong 16 server, naging imposibleng gumana nang walang luha sa napakaraming magkakaibang mga segment. Kaya nakaisip kami ng isa pang solusyon. Kinuha namin ang Netfilter stack, idinagdag ang Consul dito bilang isang data source, at nakakuha kami ng mabilis na ipinamamahaging firewall. Pinalitan nila ang mga ACL sa mga router at ginamit ang mga ito bilang panlabas at panloob na firewall. Upang dynamic na pamahalaan ang tool, binuo namin ang BEFW system, na ginagamit saanman: mula sa pamamahala ng access ng user sa network ng produkto hanggang sa paghihiwalay ng mga segment ng network sa isa't isa.
Sasabihin niya sa iyo kung paano gumagana ang lahat at kung bakit dapat mong tingnang mabuti ang sistemang ito. Ivan Agarkov () ay ang pinuno ng grupo ng seguridad sa imprastraktura ng dibisyon ng Pagpapanatili sa sentro ng pag-unlad ng Minsk ng kumpanya. Si Ivan ay isang tagahanga ng SELinux, mahilig sa Perl, at nagsusulat ng code. Bilang pinuno ng pangkat ng seguridad ng impormasyon, regular siyang nagtatrabaho sa mga log, backup at R&D upang protektahan ang Wargaming mula sa mga hacker at matiyak ang operasyon ng lahat ng mga server ng laro sa kumpanya.
kasaysayan
Bago ko sabihin sa iyo kung paano namin ginawa ito, sasabihin ko sa iyo kung paano namin ito napunta sa unang lugar at kung bakit ito kailangan. Para magawa ito, bumalik tayo sa 9 na taon: 2010, kalalabas lang ng World of Tanks. Ang Wargaming ay may humigit-kumulang 50 server.
Chart ng paglago ng server ng kumpanya.
Nagkaroon kami ng isang modelo ng network. Para sa oras na iyon ito ay pinakamainam.
Modelo ng network noong 2010.
May mga masasamang tao sa front end na gustong sirain kami, ngunit mayroon itong firewall. Walang firewall sa backend, ngunit mayroong 50 server doon, alam namin silang lahat. Lahat ay gumagana nang maayos.
Sa loob ng 4 na taon, ang fleet ng server ay lumago ng 100 beses, hanggang 5000. Ang mga unang nakahiwalay na network ay lumitaw - pagtatanghal: hindi sila maaaring pumunta sa produksyon, at madalas na may mga bagay na tumatakbo doon na maaaring mapanganib.
Modelo ng network noong 2014.
Sa pamamagitan ng inertia, ginamit namin ang parehong mga piraso ng hardware, at ang lahat ng gawain ay isinagawa sa mga nakahiwalay na VLAN: Ang mga ACL ay isinusulat sa mga VLAN, na nagpapahintulot o tumatanggi sa ilang uri ng koneksyon.
Noong 2016, umabot sa 8000 ang bilang ng mga server. Nakuha ng Wargaming ang iba pang mga studio, at lumitaw ang mga karagdagang affiliate network. Tila sa amin sila, ngunit hindi lubos: Ang VLAN ay madalas na hindi gumagana para sa mga kasosyo, kailangan mong gumamit ng VPN sa VRF, ang paghihiwalay ay nagiging mas kumplikado. Lumaki ang ACL insulation mixture.
Modelo ng network noong 2016.
Sa simula ng 2018, ang fleet ng mga makina ay lumago sa 16. Mayroong 000 na mga segment, at hindi namin binilang ang natitira, kabilang ang mga sarado kung saan naka-imbak ang data ng pananalapi. Ang mga network ng container (Kubernetes), DevOps, mga cloud network na konektado sa pamamagitan ng VPN, halimbawa, mula sa isang IVS, ay lumitaw. Mayroong maraming mga patakaran - ito ay masakit.
Modelo ng network at mga paraan ng paghihiwalay sa 2018.
Para sa paghihiwalay ginamit namin ang: VLAN na may ACL sa L2, VRF na may ACL sa L3, VPN at marami pang iba. Sobra.
Mga Problema
Nabubuhay ang lahat sa ACL at VLAN. Ano ang mali? Ang tanong na ito ay sasagutin ni Harold, itinatago ang sakit.
Maraming mga problema, ngunit mayroong limang malalaking problema.
- Geometric na pagtaas ng presyo para sa mga bagong panuntunan. Nagtagal ang bawat bagong panuntunan upang idagdag kaysa sa nauna, dahil kailangan munang makita kung mayroon nang ganoong panuntunan.
- Walang firewall sa loob ng mga segment. Ang mga segment ay kahit papaano ay hiwalay sa isa't isa, at wala nang sapat na mapagkukunan sa loob.
- Ang mga patakaran ay inilapat nang mahabang panahon. Ang mga operator ay maaaring sumulat ng isang lokal na panuntunan sa pamamagitan ng kamay sa loob ng isang oras. Ang global ay tumagal ng ilang araw.
- Mga kahirapan sa mga panuntunan sa pag-audit. Mas tiyak, hindi ito posible. Ang mga unang panuntunan ay isinulat noong 2010, at karamihan sa kanilang mga may-akda ay hindi na nagtrabaho para sa kumpanya.
- Mababang antas ng kontrol sa imprastraktura. Ito ang pangunahing problema - hindi natin alam kung ano ang nangyayari sa ating bansa.
Ganito ang hitsura ng isang network engineer noong 2018 nang marinig niya ang: βNeed some more ACL.β
Solusyon
Sa simula ng 2018, napagpasyahan na gumawa ng isang bagay tungkol dito.
Ang presyo ng mga pagsasama ay patuloy na lumalaki. Ang panimulang punto ay ang malalaking data center ay huminto sa pagsuporta sa mga nakahiwalay na VLAN at ACL dahil ang mga device ay naubusan ng memorya.
Solusyon: inalis namin ang human factor at automated ang probisyon ng access sa maximum.
Ang mga bagong panuntunan ay tumatagal ng mahabang panahon upang mailapat. Solusyon: pabilisin ang paglalapat ng mga patakaran, gawin itong distributed at parallel. Nangangailangan ito ng isang distributed system upang ang mga panuntunan ay maihatid mismo, nang walang rsync o SFTP sa isang libong system.
Walang firewall sa loob ng mga segment. Nagsimulang dumating sa amin ang firewall sa loob ng mga segment nang lumitaw ang iba't ibang serbisyo sa loob ng parehong network. Solusyon: gumamit ng firewall sa antas ng host - mga firewall na nakabatay sa host. Halos saanman mayroon kaming Linux, at saanman mayroon kaming mga iptable, hindi ito problema.
Mga kahirapan sa mga panuntunan sa pag-audit. Solusyon: Panatilihin ang lahat ng mga panuntunan sa isang lugar para sa pagsusuri at pamamahala, para ma-audit namin ang lahat.
Mababang antas ng kontrol sa imprastraktura. Solusyon: kumuha ng imbentaryo ng lahat ng serbisyo at mga access sa pagitan ng mga ito.
Ito ay higit pa sa isang prosesong administratibo kaysa sa isang teknikal. Minsan mayroon kaming 200-300 bagong release sa isang linggo, lalo na sa mga promosyon at holiday. Bukod dito, ito ay para lamang sa isang koponan ng aming mga DevOps. Sa napakaraming release, imposibleng makita kung anong mga port, IP, at integration ang kailangan. Samakatuwid, kailangan namin ng espesyal na sinanay na mga tagapamahala ng serbisyo na nagtanong sa mga koponan: "Ano pa rin ang mayroon at bakit mo ito ibinalita?"
Matapos ang lahat ng aming inilunsad, nagsimulang magmukhang ganito ang isang network engineer noong 2019.
Consul
Napagpasyahan namin na ilagay namin ang lahat ng aming nahanap sa tulong ng mga tagapamahala ng serbisyo sa Consul at mula doon ay magsusulat kami ng mga panuntunan sa iptables.
Paano namin napagdesisyunan na gawin ito?
- Kokolektahin namin ang lahat ng serbisyo, network at user.
- Gumawa tayo ng mga panuntunan sa iptables batay sa kanila.
- I-automate namin ang kontrol.
- ....
- KITA.
Ang Consul ay hindi isang malayuang API, maaari itong tumakbo sa bawat node at sumulat sa mga iptable. Ang natitira na lang ay magkaroon ng mga awtomatikong kontrol na maglilinis ng mga hindi kinakailangang bagay, at ang karamihan sa mga problema ay malulutas! Aayusin natin ang natitira habang pupunta tayo.
Bakit Consul?
Napatunayang mabuti ang sarili. Noong 2014-15, ginamit namin ito bilang backend para sa Vault, kung saan nag-iimbak kami ng mga password.
Hindi nawawala ang data. Sa panahon ng paggamit, hindi nawalan ng data si Consul sa isang aksidente. Ito ay isang malaking plus para sa isang firewall management system.
Pinapabilis ng mga koneksyon ng P2P ang pagkalat ng pagbabago. Sa P2P, mabilis na dumarating ang lahat ng pagbabago, hindi na kailangang maghintay ng ilang oras.
Maginhawang REST API. Isinaalang-alang din namin ang Apache ZooKeeper, ngunit wala itong REST API, kaya kakailanganin mong mag-install ng mga saklay.
Gumagana bilang parehong Key Vault (KV) at Direktoryo (Service Discovery). Maaari kang mag-imbak ng mga serbisyo, katalogo, at data center nang sabay-sabay. Ito ay maginhawa hindi lamang para sa amin, kundi pati na rin para sa mga kalapit na koponan, dahil kapag bumubuo ng isang pandaigdigang serbisyo, malaki ang iniisip namin.
Nakasulat sa Go, na bahagi ng Stack ng Wargaming. Gustung-gusto namin ang wikang ito, marami kaming mga developer ng Go.
Napakahusay na sistema ng ACL. Sa Consul, maaari mong gamitin ang mga ACL para kontrolin kung sino ang nagsusulat ng kung ano. Ginagarantiya namin na ang mga panuntunan sa firewall ay hindi magkakapatong sa anumang bagay at hindi kami magkakaroon ng mga problema dito.
Ngunit ang Consul ay mayroon ding mga kakulangan.
- Hindi sumusukat sa loob ng isang data center maliban kung mayroon kang bersyon ng negosyo. Ito ay nasusukat lamang ng pederasyon.
- Napaka depende sa kalidad ng network at server load. Ang Consul ay hindi gagana nang maayos bilang isang server sa isang abalang server kung mayroong anumang mga lags sa network, halimbawa, hindi pantay na bilis. Ito ay dahil sa mga koneksyon sa P2P at pag-update ng mga modelo ng pamamahagi.
- Kahirapan sa pagsubaybay sa availability. Sa status ng Consul ay masasabi niyang maayos na ang lahat, ngunit matagal na siyang namatay.
Nalutas namin ang karamihan sa mga problemang ito habang ginagamit ang Consul, kaya naman pinili namin ito. Ang kumpanya ay may mga plano para sa isang alternatibong backend, ngunit natutunan naming harapin ang mga problema at kasalukuyang nakatira sa Consul.
Paano gumagana ang Consul
Mag-i-install kami ng tatlo hanggang limang server sa isang conditional data center. Hindi gagana ang isa o dalawang server: hindi nila magagawang ayusin ang isang korum at magpasya kung sino ang tama at kung sino ang mali kapag hindi tumugma ang data. Higit sa lima ay walang kahulugan, ang produktibo ay bababa.
Kumonekta ang mga kliyente sa mga server sa anumang pagkakasunud-sunod: ang parehong mga ahente, gamit lamang ang bandila server = false.
Pagkatapos nito, makakatanggap ang mga kliyente ng isang listahan ng mga koneksyon sa P2P at bumuo ng mga koneksyon sa kanilang mga sarili.
Sa pandaigdigang antas, ikinonekta namin ang ilang mga data center. Kumokonekta rin sila ng P2P at nakikipag-usap.
Kapag gusto naming kumuha ng data mula sa isa pang data center, ang kahilingan ay napupunta mula sa server patungo sa server. Ang iskema na ito ay tinatawag Serf protocol. Ang Serf protocol, tulad ng Consul, ay binuo ng HashiCorp.
Ilang mahahalagang katotohanan tungkol sa Consul
May dokumentasyon ang Consul na naglalarawan kung paano ito gumagana. Ibibigay ko lamang ang mga piling katotohanan na nararapat malaman.
Ang mga consul server ay pumipili ng isang master mula sa mga botante. Pinipili ng Consul ang isang master mula sa listahan ng mga server para sa bawat data center, at lahat ng mga kahilingan ay napupunta lamang dito, anuman ang bilang ng mga server. Ang master freezing ay hindi humahantong sa muling halalan. Kung hindi napili ang master, ang mga kahilingan ay hindi sineserbisyuhan ng sinuman.
Gusto mo ba ng pahalang na pag-scale? Sorry, hindi.
Ang isang kahilingan sa isa pang data center ay napupunta mula sa master hanggang sa master, anuman ang server nito nanggaling. Ang napiling master ay tumatanggap ng 100% ng load, maliban sa load sa mga forward request. Ang lahat ng mga server sa data center ay may up-to-date na kopya ng data, ngunit isa lang ang tumutugon.
Ang tanging paraan upang masukat ay ang paganahin ang stale mode sa client.
Sa stale mode, maaari kang tumugon nang walang quorum. Ito ay isang mode kung saan ibinibigay namin ang pagkakapare-pareho ng data, ngunit magbasa nang mas mabilis kaysa karaniwan, at anumang server ang tumugon. Naturally, nagre-record lamang sa pamamagitan ng master.
Hindi kinokopya ng Consul ang data sa pagitan ng mga data center. Kapag ang isang federation ay binuo, ang bawat server ay magkakaroon lamang ng sarili nitong data. Para sa iba, palagi siyang lumilingon sa iba.
Ang atomicity ng mga operasyon ay hindi ginagarantiyahan sa labas ng isang transaksyon. Tandaan na hindi lang ikaw ang makakapagpabago ng mga bagay. Kung iba ang gusto mo, magsagawa ng transaksyon na may lock.
Ang mga pagpapatakbo ng pagharang ay hindi ginagarantiyahan ang pag-lock. Ang kahilingan ay mula sa master hanggang master, at hindi direkta, kaya walang garantiya na gagana ang pagharang kapag nag-block ka, halimbawa, sa isa pang data center.
Hindi rin ginagarantiya ng ACL ang pag-access (sa maraming kaso). Maaaring hindi gumana ang ACL dahil naka-store ito sa isang federation data center - sa ACL data center (Pangunahing DC). Kung hindi ka sasagutin ng DC, hindi gagana ang ACL.
Ang isang nakapirming master ay magiging sanhi ng pag-freeze ng buong pederasyon. Halimbawa, mayroong 10 data center sa isang federation, at ang isa ay may masamang network, at isang master ang nabigo. Ang bawat isa na nakikipag-usap sa kanya ay maiipit sa isang bilog: mayroong isang kahilingan, walang sagot dito, ang thread ay nag-freeze. Walang paraan upang malaman kung kailan ito mangyayari, sa loob lamang ng isang oras o dalawa ay babagsak ang buong pederasyon. Wala kang magagawa tungkol dito.
Ang katayuan, korum at mga halalan ay pinangangasiwaan ng isang hiwalay na thread. Hindi mangyayari ang muling halalan, walang ipapakita ang status. Iniisip mo na mayroon kang isang live na Konsul, nagtatanong ka, at walang nangyayari - walang sagot. Kasabay nito, ipinapakita ng status na maayos ang lahat.
Nakatagpo kami ng problemang ito at kinailangan naming buuin muli ang mga partikular na bahagi ng mga data center upang maiwasan ito.
Ang bersyon ng negosyo ng Consul Enterprise ay walang ilan sa mga disadvantages sa itaas. Mayroon itong maraming kapaki-pakinabang na pag-andar: pagpili ng mga botante, pamamahagi, pag-scale. Mayroon lamang isang "ngunit" - ang sistema ng paglilisensya para sa isang distributed system ay napakamahal.
Pag-hack ng buhay: rm -rf /var/lib/consul - isang lunas para sa lahat ng mga sakit ng ahente. Kung may hindi gumana para sa iyo, tanggalin lang ang iyong data at i-download ang data mula sa isang kopya. Malamang, magtatrabaho si Consul.
BEFW
Ngayon pag-usapan natin kung ano ang idinagdag natin sa Consul.
ay isang acronym para sa BackEndFGalitWlahat. Kinailangan kong pangalanan ang produkto kahit papaano noong nilikha ko ang repository upang mailagay ang unang pagsubok na ginawa dito. Nananatili ang pangalang ito.
Mga template ng panuntunan
Ang mga patakaran ay nakasulat sa iptables syntax.
- -N BEFW
- -P INPUT DROP
- -Isang INPUT -m estadoβestado na KAUGNAY,NAGITATAG -j TANGGAPIN
- -A INPUT -i lo -j TANGGAPIN
- -A INPUT -j BEFW
Ang lahat ay napupunta sa BEFW chain, maliban ESTABLISHED, RELATED at localhost. Ang template ay maaaring kahit ano, ito ay isang halimbawa lamang.
Paano kapaki-pakinabang ang BEFW?
Mga Serbisyo
Mayroon kaming isang serbisyo, ito ay palaging may port, isang node kung saan ito tumatakbo. Mula sa aming node, maaari naming lokal na tanungin ang ahente at malaman na mayroon kaming ilang uri ng serbisyo. Maaari ka ring maglagay ng mga tag.
Anumang serbisyo na tumatakbo at nakarehistro sa Consul ay nagiging isang iptables na panuntunan. Mayroon kaming SSH - bukas na port 22. Ang script ng Bash ay simple: curl at iptables, walang ibang kailangan.
Mga Kliyente
Paano buksan ang access hindi sa lahat, ngunit pili? Magdagdag ng mga listahan ng IP sa imbakan ng KV ayon sa pangalan ng serbisyo.
Halimbawa, gusto naming ma-access ng lahat sa ikasampung network ang serbisyo ng SSH_TCP_22. Magdagdag ng isang maliit na field ng TTL? at ngayon mayroon kaming mga pansamantalang permit, halimbawa, para sa isang araw.
Mga access
Ikinonekta namin ang mga serbisyo at kliyente: mayroon kaming serbisyo, handa na ang imbakan ng KV para sa bawat isa. Ngayon ay nagbibigay kami ng access hindi sa lahat, ngunit pili.
Grupo
Kung magsusulat tayo ng libu-libong IP para ma-access sa bawat oras, mapapagod tayo. Gumawa tayo ng mga pagpapangkat - isang hiwalay na subset sa KV. Tawagan natin itong Alias ββββ(o mga grupo) at mag-imbak ng mga grupo doon ayon sa parehong prinsipyo.
Kumonekta tayo: ngayon ay maaari nating buksan ang SSH hindi partikular para sa P2P, ngunit para sa isang buong grupo o ilang mga grupo. Sa parehong paraan, mayroong TTL - maaari kang magdagdag sa isang grupo at pansamantalang alisin mula sa grupo.
Pagsasama
Ang problema natin ay ang human factor at automation. Sa ngayon ay nalutas namin ito sa ganitong paraan.
Nakikipagtulungan kami sa Puppet, at inililipat sa kanila ang lahat ng nauugnay sa system (code ng aplikasyon). Ang Puppetdb (regular na PostgreSQL) ay nag-iimbak ng isang listahan ng mga serbisyo na tumatakbo doon, maaari silang matagpuan ayon sa uri ng mapagkukunan. Doon mo malalaman kung sino ang nag-a-apply kung saan. Mayroon din kaming pull request at merge request system para dito.
Sumulat kami ng befw-sync, isang simpleng solusyon na tumutulong sa paglilipat ng data. Una, ang sync cookies ay ina-access ng puppetdb. Ang isang HTTP API ay na-configure doon: hinihiling namin kung anong mga serbisyo ang mayroon kami, kung ano ang kailangang gawin. Pagkatapos ay humiling sila sa Consul.
May integration ba? Oo: isinulat nila ang mga patakaran at pinahintulutan ang mga Pull Requests na tanggapin. Kailangan mo ba ng isang tiyak na port o magdagdag ng isang host sa ilang grupo? Pull Request, review - wala nang "Maghanap ng 200 iba pang ACL at subukang gumawa ng isang bagay tungkol dito."
Optimization
Ang pag-ping sa localhost na may walang laman na chain ng panuntunan ay tumatagal ng 0,075 ms.
Magdagdag tayo ng 10 iptables address sa chain na ito. Bilang resulta, ang ping ay tataas ng 000 beses: ang mga iptable ay ganap na linear, ang pagproseso ng bawat address ay tumatagal ng ilang oras.
Para sa isang firewall kung saan naglilipat kami ng libu-libong ACL, marami kaming panuntunan, at ipinakikilala nito ang latency. Ito ay masama para sa mga protocol ng paglalaro.
Pero kung ilalagay natin 10 address sa ipset Ang ping ay bababa pa.
Ang punto ay ang "O" (algorithm complexity) para sa ipset ay palaging katumbas ng 1, gaano man karaming mga panuntunan ang mayroon. Totoo, may limitasyon - hindi maaaring higit sa 65535 na mga panuntunan. Sa ngayon ay nabubuhay tayo kasama nito: maaari mong pagsamahin ang mga ito, palawakin ang mga ito, gumawa ng dalawang ipset sa isa.
Imbakan
Ang isang lohikal na pagpapatuloy ng proseso ng pag-ulit ay ang pag-iimbak ng impormasyon tungkol sa mga kliyente para sa serbisyo sa ipset.
Ngayon ay mayroon kaming parehong SSH, at hindi kami sumulat ng 100 IP nang sabay-sabay, ngunit itinakda ang pangalan ng ipset kung saan kailangan naming makipag-usap, at ang sumusunod na panuntunan DROP. Maaari itong i-convert sa isang panuntunan na "Sino ang wala rito, DROP", ngunit mas malinaw ito.
Ngayon mayroon kaming mga patakaran at set. Ang pangunahing gawain ay gumawa ng isang set bago isulat ang panuntunan, dahil kung hindi man ay hindi isusulat ng mga iptable ang panuntunan.
Pangkalahatang pamamaraan
Sa anyo ng isang diagram, lahat ng sinabi ko ay ganito.
We commit to Puppet, everything is sent to the host, services dito, ipset doon, at kahit sinong hindi nakaregister doon ay bawal.
Payagan tumanggi
Upang mabilis na mailigtas ang mundo o mabilis na hindi paganahin ang isang tao, sa simula ng lahat ng mga chain gumawa kami ng dalawang ipset: rules_allow ΠΈ rules_deny. Paano ito gumagana?
Halimbawa, may gumagawa ng load sa aming Web gamit ang mga bot. Dati, kailangan mong hanapin ang kanyang IP mula sa mga log, dalhin ito sa mga inhinyero ng network, upang mahanap nila ang pinagmulan ng trapiko at i-ban siya. Parang iba na ngayon.
Ipinapadala namin ito sa Consul, maghintay ng 2,5 segundo, at tapos na. Dahil mabilis na namamahagi ang Consul sa pamamagitan ng P2P, gumagana ito saanman, sa anumang bahagi ng mundo.
Minsan ko sa paanuman ganap na tumigil sa WOT dahil sa isang pagkakamali sa firewall. rules_allow - ito ang aming insurance laban sa mga ganitong kaso. Kung nagkamali kami sa isang lugar sa firewall, may naka-block sa isang lugar, maaari kaming palaging magpadala ng kondisyon 0.0/0upang mabilis na kunin ang lahat. Mamaya ay ayusin namin ang lahat sa pamamagitan ng kamay.
Iba pang set
Maaari kang magdagdag ng anumang iba pang set sa espasyo $IPSETS$.
Para saan? Minsan kailangan ng isang tao ang ipset, halimbawa, upang tularan ang pagsasara ng ilang bahagi ng cluster. Kahit sino ay maaaring magdala ng anumang set, pangalanan ang mga ito, at sila ay kukunin mula sa Consul. Kasabay nito, ang mga set ay maaaring lumahok sa mga panuntunan ng iptables o kumilos bilang isang koponan NOOP: Ang pagkakapare-pareho ay pananatilihin ng daemon.
Mga gumagamit
Dati, ganito ito: nakakonekta ang user sa network at nakatanggap ng mga parameter sa pamamagitan ng domain. Bago ang pagdating ng mga bagong henerasyong firewall, hindi alam ng Cisco kung paano mauunawaan kung nasaan ang gumagamit at kung nasaan ang IP. Samakatuwid, ang pag-access ay ibinigay lamang sa pamamagitan ng hostname ng makina.
Anong ginawa natin? Natigil kami sa sandaling natanggap namin ang address. Kadalasan ito ay dot1x, Wi-Fi o VPN - lahat ay dumadaan sa RADIUS. Para sa bawat user, gumagawa kami ng grupo ayon sa username at naglalagay kami ng IP dito na may TTL na katumbas ng dhcp.lease nito - sa sandaling mag-expire ito, mawawala ang panuntunan.
Ngayon ay maaari na naming buksan ang access sa mga serbisyo, tulad ng ibang mga grupo, sa pamamagitan ng username. Inalis namin ang sakit sa mga hostname kapag nagbago ang mga ito, at inalis namin ang pasanin sa mga network engineer dahil hindi na nila kailangan ang Cisco. Ngayon ang mga inhinyero mismo ay nagrerehistro ng access sa kanilang mga server.
Pagkakabukod
Kasabay nito, sinimulan naming lansagin ang pagkakabukod. Nagsagawa ng imbentaryo ang mga tagapamahala ng serbisyo, at sinuri namin ang lahat ng aming network. Hatiin natin sila sa parehong mga grupo, at sa mga kinakailangang server ay idinagdag ang mga grupo, halimbawa, upang tanggihan. Ngayon ang parehong staging isolation ay nagtatapos sa rules_deny ng production, ngunit hindi sa production mismo.
Gumagana nang mabilis at simple ang scheme: inaalis namin ang lahat ng ACL sa mga server, binabawasan ang hardware, at binabawasan ang bilang ng mga nakahiwalay na VLAN.
Kontrol ng integridad
Dati, mayroon kaming espesyal na trigger na nag-ulat kapag may binago nang manu-mano ang panuntunan ng firewall. Nagsusulat ako ng isang malaking linter para sa pagsuri sa mga panuntunan ng firewall, mahirap. Ang integridad ay kontrolado na ngayon ng BEFW. Masigasig niyang tinitiyak na hindi magbabago ang mga patakarang ginagawa niya. Kung binago ng isang tao ang mga panuntunan sa firewall, babaguhin nito ang lahat pabalik. βMabilis akong nag-set up ng proxy para makapagtrabaho ako mula sa bahayββwala nang ganoong mga opsyon.
Kinokontrol ng BEFW ang ipset mula sa mga serbisyo at listahan sa befw.conf, ang mga patakaran ng mga serbisyo sa BEFW chain. Ngunit hindi nito sinusubaybayan ang iba pang mga kadena at mga patakaran at iba pang mga ipset.
Proteksyon sa pag-crash
Palaging iniimbak ng BEFW ang huling kilalang magandang estado nang direkta sa state.bin binary structure. Kung may mali, palagi itong bumabalik sa ganitong estado.bin.
Ito ay insurance laban sa hindi matatag na operasyon ng Consul, kapag hindi ito nagpadala ng data o may nagkamali at gumamit ng mga panuntunan na hindi maaaring ilapat. Upang matiyak na hindi tayo maiiwan na walang firewall, babalik ang BEFW sa pinakabagong estado kung may naganap na error sa anumang yugto.
Sa mga kritikal na sitwasyon, ito ay isang garantiya na maiiwan tayo ng gumaganang firewall. Binubuksan namin ang lahat ng mga gray na network sa pag-asa na darating ang admin at ayusin ito. Balang araw ay ilalagay ko ito sa mga config, ngunit ngayon ay mayroon lamang kaming tatlong kulay-abo na network: 10/8, 172/12 at 192.168/16. Sa loob ng aming Consul, ito ay isang mahalagang tampok na tumutulong sa amin na umunlad pa.
Demo: sa panahon ng ulat, ipinakita ni Ivan ang demo mode ng BEFW. Mas madaling panoorin ang demonstrasyon . Available ang demo source code .
Pitfalls
Sasabihin ko sa iyo ang tungkol sa mga bug na nakatagpo namin.
ipset add set 0.0.0.0/0. Ano ang mangyayari kung magdagdag ka ng 0.0.0.0/0 sa ipset? Lahat ba ng IP ay idadagdag? Magagamit ba ang Internet access?
Hindi, makakatanggap kami ng bug na nagkakahalaga ng dalawang oras ng downtime. Bukod dito, ang bug ay hindi gumana mula noong 2016, ito ay matatagpuan sa RedHat Bugzilla sa ilalim ng numero #1297092, at nakita namin ito nang hindi sinasadya - mula sa ulat ng isang developer.
Ito ay ngayon ay isang mahigpit na tuntunin sa BEFW na 0.0.0.0/0 nagiging dalawang address: 0.0.0.0/1 ΠΈ 128.0.0.0/1.
ipset restore set < file. Ano ang ginagawa ng ipset kapag sinabihan mo ito restore? Sa tingin mo ba ito ay gumagana katulad ng iptables? Mabawi ba nito ang data?
Walang ganoon - ito ay nagsasama, at ang mga lumang address ay hindi napupunta kahit saan, hindi mo hinaharangan ang pag-access.
Nakakita kami ng bug noong sinusuri ang paghihiwalay. Ngayon ay mayroong isang medyo kumplikadong sistema - sa halip na restore held create temp, pagkatapos restore flush temp ΠΈ restore temp. Sa dulo ng swap: para sa atomicity, dahil kung gagawin mo muna ito flush at sa sandaling ito ay may dumating na packet, ito ay itatapon at may mali. Kaya may kaunting black magic doon.
consul kv get -datacenter=other. Tulad ng sinabi ko, sa palagay namin ay humihingi kami ng ilang data, ngunit makakakuha kami ng data o isang error. Magagawa natin ito sa pamamagitan ng lokal na Konsul, ngunit sa kasong ito, pareho silang mag-freeze.
Ang lokal na kliyente ng Consul ay isang wrapper sa HTTP API. Ngunit ito ay nakabitin lamang at hindi tumutugon sa Ctrl+C, o Ctrl+Z, o anumang bagay, lamang kill -9 sa susunod na console. Nakatagpo namin ito noong kami ay nagtatayo ng isang malaking kumpol. Ngunit wala pa kaming solusyon; naghahanda kaming ayusin ang error na ito sa Consul.
Ang pinuno ng konsul ay hindi tumutugon. Ang aming master sa data center ay hindi tumutugon, sa palagay namin: "Marahil ang algorithm ng muling pagpili ay gagana ngayon?"
Hindi, hindi ito gagana, at ang pagsubaybay ay hindi magpapakita ng anuman: Sasabihin ng Consul na mayroong index ng pangako, natagpuan ang isang pinuno, maayos ang lahat.
Paano natin ito haharapin? service consul restart sa cron bawat oras. Kung mayroon kang 50 server, walang malaking problema. Kapag mayroong 16 sa kanila, mauunawaan mo kung paano ito gumagana.
Konklusyon
Bilang resulta, natanggap namin ang mga sumusunod na pakinabang:
- 100% coverage ng lahat ng Linux machine.
- Bilis
- Automation.
- Pinalaya namin ang mga inhinyero ng hardware at network mula sa pang-aalipin.
- Ang mga posibilidad ng pagsasama ay lumitaw na halos walang limitasyon: kahit na sa Kubernetes, kahit na may Ansible, kahit na may Python.
Cons: Konsul, kung saan kailangan na nating mabuhay, at ang napakataas na halaga ng pagkakamali. Bilang halimbawa, minsan sa 6 pm (prime time sa Russia) ay may ini-edit ako sa mga listahan ng mga network. Nagtatayo lang kami ng insulasyon sa BEFW noong panahong iyon. Nagkamali ako sa isang lugar, tila maling maskara ang ipinahiwatig ko, ngunit nahulog ang lahat sa loob ng dalawang segundo. Ang pagsubaybay ay lumiwanag, ang tagasuporta na naka-duty ay tumatakbo: "Amin ang lahat!" Naging kulay abo ang pinuno ng departamento nang ipaliwanag niya sa negosyo kung bakit nangyari ito.
Ang halaga ng error ay napakataas kaya nakaisip kami ng sarili naming kumplikadong pamamaraan sa pag-iwas. Kung ipapatupad mo ito sa isang malaking production site, hindi mo kailangang magbigay ng master token over Consul sa lahat. Magtatapos ito ng masama.
Gastos Sumulat ako ng code sa loob ng 400 oras nang mag-isa. Ang aking pangkat ng 4 na tao ay gumugugol ng 10 oras sa isang buwan sa suporta para sa lahat. Kung ikukumpara sa presyo ng anumang bagong henerasyong firewall, libre ito.
Mga plano. Ang pangmatagalang plano ay maghanap ng alternatibong transportasyon na palitan o umakma sa Consul. Marahil ito ay magiging Kafka o isang katulad nito. Ngunit sa mga susunod na taon ay titira tayo sa Consul.
Mga agarang plano: pagsasama sa Fail2ban, sa pagsubaybay, sa mga nftable, posibleng sa iba pang mga distribusyon, sukatan, advanced na pagsubaybay, pag-optimize. Ang suporta ng Kubernetes ay nasa isang lugar din sa mga plano, dahil mayroon kaming ilang mga kumpol at pagnanais.
Higit pa mula sa mga plano:
- maghanap ng mga anomalya sa trapiko;
- pamamahala ng mapa ng network;
- Suporta ng Kubernetes;
- pag-assemble ng mga pakete para sa lahat ng mga sistema;
- Web-UI.
Patuloy kaming nagsusumikap sa pagpapalawak ng configuration, pagpapataas ng mga sukatan at pag-optimize.
Sumali sa proyekto. Ang proyekto ay naging cool, ngunit, sa kasamaang-palad, ito ay isa pa ring proyekto ng isang tao. Pumunta sa at subukang gumawa ng isang bagay: mangako, sumubok, magmungkahi ng isang bagay, ibigay ang iyong pagtatasa.
Samantala kami ay naghahanda para sa , na magaganap sa Abril 6 at 7 sa St. Petersburg, at iniimbitahan namin ang mga developer ng mga high-load system . Alam na ng mga bihasang tagapagsalita kung ano ang gagawin, ngunit para sa mga bago sa pagsasalita ay inirerekomenda namin ang hindi bababa sa . Ang pakikilahok sa kumperensya bilang tagapagsalita ay may ilang mga pakinabang. Maaari mong basahin kung alin, halimbawa, sa dulo .
Pinagmulan: www.habr.com