Pada tahun 2010 perusahaan ada 50 server dan model jaringan sederhana: backend, frontend dan firewall. Jumlah server bertambah, model menjadi lebih kompleks: staging, mengisolasi VLAN dengan ACL, lalu VPN dengan VRF, VLAN dengan ACL di L2, VRF dengan ACL di L3. Kepala berputar? Nanti akan lebih menyenangkan.
Ketika terdapat 16 server, menjadi mustahil untuk bekerja tanpa hambatan dengan begitu banyak segmen yang heterogen. Jadi kami menemukan solusi lain. Kami mengambil tumpukan Netfilter, menambahkan Konsul ke dalamnya sebagai sumber data, dan kami mendapatkan firewall yang didistribusikan dengan cepat. Mereka menggantikan ACL pada router dan menggunakannya sebagai firewall eksternal dan internal. Untuk mengelola alat ini secara dinamis, kami mengembangkan sistem BEFW, yang digunakan di mana saja: mulai dari mengelola akses pengguna ke jaringan produk hingga mengisolasi segmen jaringan satu sama lain.
Dia akan memberi tahu Anda cara kerjanya dan mengapa Anda harus melihat lebih dekat sistem ini. Ivan Agarkov () adalah kepala kelompok keamanan infrastruktur di divisi Pemeliharaan di pusat pengembangan perusahaan di Minsk. Ivan adalah penggemar SELinux, menyukai Perl, dan menulis kode. Sebagai kepala kelompok keamanan informasi, ia secara teratur bekerja dengan log, pencadangan, dan penelitian dan pengembangan untuk melindungi Wargaming dari peretas dan memastikan pengoperasian semua server game di perusahaan.
sejarah
Sebelum saya memberi tahu Anda bagaimana kami melakukannya, saya akan memberi tahu Anda bagaimana kami sampai pada hal ini dan mengapa hal ini diperlukan. Untuk melakukan ini, mari kita kembali ke 9 tahun: 2010, World of Tanks baru saja muncul. Wargaming memiliki sekitar 50 server.
Grafik pertumbuhan server perusahaan.
Kami memiliki model jaringan. Untuk saat itu sudah optimal.
Model jaringan pada tahun 2010.
Ada orang jahat di front end yang ingin menghancurkan kita, tapi dia punya firewall. Tidak ada firewall di backend, tapi ada 50 server di sana, kami tahu semuanya. Semuanya bekerja dengan baik.
Dalam 4 tahun, armada server tumbuh 100 kali lipat, menjadi 5000. Jaringan terisolasi pertama muncul - staging: jaringan tersebut tidak dapat masuk ke produksi, dan sering kali ada hal-hal yang berjalan di sana yang bisa berbahaya.
Model jaringan pada tahun 2014.
Secara inersia, kami menggunakan perangkat keras yang sama, dan semua pekerjaan dilakukan pada VLAN yang terisolasi: ACL ditulis ke VLAN, yang mengizinkan atau menolak beberapa jenis koneksi.
Pada tahun 2016, jumlah server mencapai 8000. Wargaming menyerap studio lain, dan jaringan afiliasi tambahan bermunculan. Tampaknya itu milik kita, tetapi tidak sepenuhnya: VLAN sering kali tidak berfungsi untuk mitra, Anda harus menggunakan VPN dengan VRF, isolasi menjadi lebih rumit. Campuran isolasi ACL bertambah.
Model jaringan pada tahun 2016.
Awal tahun 2018 armada mesin bertambah menjadi 16, ada 000 segmen, sisanya tidak kami hitung, termasuk segmen tertutup yang menyimpan data keuangan. Jaringan kontainer (Kubernetes), DevOps, jaringan cloud yang terhubung melalui VPN, misalnya dari IVS, telah muncul. Ada banyak aturan - itu menyakitkan.
Model jaringan dan metode isolasi pada tahun 2018.
Untuk isolasi kami menggunakan: VLAN dengan ACL di L2, VRF dengan ACL di L3, VPN dan banyak lagi. Terlalu banyak.
Masalah
Semua orang hidup dengan ACL dan VLAN. Apa yang salah? Pertanyaan ini akan dijawab oleh Harold, menyembunyikan rasa sakitnya.
Ada banyak masalah, tapi ada lima masalah besar.
- Kenaikan harga geometris untuk aturan baru. Setiap aturan baru membutuhkan waktu lebih lama untuk ditambahkan dibandingkan aturan sebelumnya, karena perlu dilihat terlebih dahulu apakah sudah ada aturan seperti itu.
- Tidak ada firewall di dalam segmen. Segmen-segmen tersebut entah bagaimana terpisah satu sama lain, dan sumber daya di dalamnya sudah tidak cukup.
- Aturan itu diterapkan sejak lama. Operator dapat menulis satu peraturan lokal dengan tangan dalam satu jam. Yang global memakan waktu beberapa hari.
- Kesulitan dengan aturan audit. Lebih tepatnya, hal itu tidak mungkin terjadi. Aturan pertama ditulis pada tahun 2010, dan sebagian besar pembuatnya tidak lagi bekerja untuk perusahaan tersebut.
- Tingkat kontrol infrastruktur yang rendah. Ini adalah masalah utama – kami tidak mengetahui dengan baik apa yang sedang terjadi di negara kami.
Seperti inilah rupa seorang teknisi jaringan pada tahun 2018 ketika dia mendengar: “Perlu lebih banyak ACL.”
Solusi
Pada awal tahun 2018, diputuskan untuk melakukan sesuatu.
Harga integrasi terus meningkat. Titik awalnya adalah pusat data besar berhenti mendukung VLAN dan ACL yang terisolasi karena perangkat kehabisan memori.
Solusi: kami menghilangkan faktor manusia dan mengotomatiskan penyediaan akses secara maksimal.
Aturan baru ini membutuhkan waktu lama untuk diterapkan. Solusi: mempercepat penerapan aturan, membuatnya terdistribusi dan paralel. Hal ini memerlukan sistem terdistribusi sehingga aturan dikirimkan sendiri, tanpa rsync atau SFTP ke ribuan sistem.
Tidak ada firewall di dalam segmen. Firewall dalam segmen mulai mendatangi kami ketika layanan berbeda muncul dalam jaringan yang sama. Solusi: gunakan firewall di tingkat host – firewall berbasis host. Hampir di mana pun kita memiliki Linux, dan di mana pun kita memiliki iptables, ini bukan masalah.
Kesulitan dengan aturan audit. Solusi: Simpan semua peraturan di satu tempat untuk ditinjau dan dikelola, sehingga kami dapat mengaudit semuanya.
Rendahnya tingkat kontrol atas infrastruktur. Solusi: lakukan inventarisasi semua layanan dan akses di antara layanan tersebut.
Ini lebih merupakan proses administratif dibandingkan proses teknis. Terkadang kami memiliki 200-300 rilis baru dalam seminggu, terutama selama promosi dan hari libur. Terlebih lagi, ini hanya untuk satu tim DevOps kami. Dengan banyaknya rilis, tidak mungkin untuk melihat port, IP, dan integrasi apa yang diperlukan. Oleh karena itu, kami memerlukan manajer layanan terlatih yang bertanya kepada tim: “Apa saja yang ada di sana dan mengapa Anda mengungkitnya?”
Setelah semua yang kami luncurkan, network engineer pada tahun 2019 mulai terlihat seperti ini.
Konsul
Kami memutuskan bahwa kami akan memasukkan semua yang kami temukan dengan bantuan manajer layanan ke Konsul dan dari sana kami akan menulis aturan iptables.
Bagaimana kami memutuskan untuk melakukan ini?
- Kami akan mengumpulkan semua layanan, jaringan, dan pengguna.
- Mari kita buat aturan iptables berdasarkan aturan tersebut.
- Kami mengotomatiskan kontrol.
- ....
- LABA.
Konsul bukanlah API jarak jauh, ia dapat berjalan di setiap node dan menulis ke iptables. Yang tersisa hanyalah menghadirkan kontrol otomatis yang akan membersihkan hal-hal yang tidak perlu, dan sebagian besar masalah akan terpecahkan! Kami akan mengerjakan sisanya sambil jalan.
Mengapa Konsul?
Telah membuktikan dirinya dengan baik. Pada tahun 2014-15, kami menggunakannya sebagai backend untuk Vault, tempat kami menyimpan kata sandi.
Tidak kehilangan data. Selama penggunaan, Konsul tidak kehilangan data dalam satu kecelakaan pun. Ini merupakan nilai tambah yang besar untuk sistem manajemen firewall.
Koneksi P2P mempercepat penyebaran perubahan. Dengan P2P, semua perubahan terjadi dengan cepat, tidak perlu menunggu berjam-jam.
API REST yang nyaman. Kami juga mempertimbangkan Apache ZooKeeper, tetapi tidak memiliki REST API, jadi Anda harus memasang kruk.
Berfungsi sebagai Key Vault (KV) dan Direktori (Service Discovery). Anda dapat menyimpan layanan, katalog, dan pusat data sekaligus. Hal ini nyaman tidak hanya bagi kami, tetapi juga bagi tim tetangga, karena ketika membangun layanan global, kami berpikir besar.
Ditulis di Go, yang merupakan bagian dari tumpukan Wargaming. Kami menyukai bahasa ini, kami memiliki banyak pengembang Go.
Sistem ACL yang kuat. Di Konsul, Anda dapat menggunakan ACL untuk mengontrol siapa yang menulis apa. Kami menjamin bahwa aturan firewall tidak akan tumpang tindih dengan aturan lainnya dan kami tidak akan mengalami masalah dengan hal ini.
Namun Konsul juga memiliki kekurangan.
- Tidak berskala dalam pusat data kecuali Anda memiliki versi bisnis. Ini hanya dapat diukur berdasarkan federasi.
- Sangat bergantung pada kualitas jaringan dan beban server. Konsul tidak akan berfungsi dengan baik sebagai server pada server yang sibuk jika terjadi kelambatan pada jaringan, misalnya kecepatan tidak merata. Hal ini disebabkan oleh koneksi P2P dan pembaruan model distribusi.
- Kesulitan memantau ketersediaan. Dalam status Konsul dia bisa mengatakan semuanya baik-baik saja, tapi dia sudah lama meninggal.
Kami memecahkan sebagian besar masalah ini saat menggunakan Konsul, itulah sebabnya kami memilihnya. Perusahaan mempunyai rencana untuk backend alternatif, namun kami telah belajar untuk mengatasi masalah dan saat ini tinggal bersama Konsul.
Cara kerja Konsul
Kami akan memasang tiga hingga lima server di pusat data bersyarat. Satu atau dua server tidak akan berfungsi: mereka tidak akan mampu mengatur kuorum dan memutuskan siapa yang benar dan siapa yang salah jika datanya tidak cocok. Lebih dari lima tidak masuk akal, produktivitas akan turun.
Klien terhubung ke server dalam urutan apa pun: agen yang sama, hanya dengan bendera server = false.
Setelah ini, klien menerima daftar koneksi P2P dan membangun koneksi di antara mereka sendiri.
Di tingkat global, kami menghubungkan beberapa pusat data. Mereka juga menghubungkan P2P dan berkomunikasi.
Saat kita ingin mengambil data dari pusat data lain, permintaannya berpindah dari server ke server. Skema ini disebut Protokol budak. Protokol Serf, seperti Konsul, dikembangkan oleh HashiCorp.
Beberapa fakta penting tentang Konsul
Konsul memiliki dokumentasi yang menjelaskan cara kerjanya. Saya hanya akan memberikan fakta-fakta terpilih yang perlu diketahui.
Server konsul memilih master dari antara para pemilih. Konsul memilih master dari daftar server untuk setiap pusat data, dan semua permintaan hanya ditujukan ke sana, berapa pun jumlah servernya. Pembekuan master tidak mengarah pada terpilihnya kembali. Jika master tidak dipilih, permintaan tidak dilayani oleh siapa pun.
Apakah Anda ingin penskalaan horizontal? Maaf, tidak.
Permintaan ke pusat data lain berpindah dari master ke master, terlepas dari server mana permintaan tersebut datang. Master yang dipilih menerima 100% beban, kecuali beban pada permintaan penerusan. Semua server di pusat data memiliki salinan data terkini, namun hanya satu yang merespons.
Satu-satunya cara untuk melakukan penskalaan adalah dengan mengaktifkan mode lama pada klien.
Dalam mode basi, Anda dapat merespons tanpa kuorum. Ini adalah mode di mana kami mengabaikan konsistensi data, tetapi membaca sedikit lebih cepat dari biasanya, dan server mana pun merespons. Wajar saja, rekaman hanya melalui master.
Konsul tidak menyalin data antar pusat data. Ketika sebuah federasi dibentuk, setiap server hanya akan memiliki datanya sendiri. Bagi orang lain, dia selalu berpaling ke orang lain.
Atomisitas operasi tidak dijamin di luar transaksi. Ingatlah bahwa Anda bukanlah satu-satunya yang bisa mengubah keadaan. Jika Anda menginginkannya berbeda, lakukan transaksi dengan kunci.
Operasi pemblokiran tidak menjamin penguncian. Permintaan berpindah dari master ke master, dan tidak secara langsung, jadi tidak ada jaminan bahwa pemblokiran akan berhasil saat Anda memblokir, misalnya, di pusat data lain.
ACL juga tidak menjamin akses (dalam banyak kasus). ACL mungkin tidak berfungsi karena disimpan di satu pusat data federasi - di pusat data ACL (DC Primer). Jika DC tidak menjawab Anda, ACL tidak akan berfungsi.
Satu master yang dibekukan akan menyebabkan seluruh federasi membeku. Misalnya, ada 10 pusat data dalam satu federasi, dan satu memiliki jaringan buruk, dan satu master gagal. Setiap orang yang berkomunikasi dengannya akan terjebak dalam lingkaran: ada permintaan, tidak ada jawaban, utasnya macet. Tidak ada cara untuk mengetahui kapan ini akan terjadi, hanya dalam satu atau dua jam seluruh federasi akan jatuh. Tidak ada yang dapat Anda lakukan mengenai hal itu.
Status, kuorum, dan pemilihan ditangani oleh rangkaian terpisah. Pemilihan ulang tidak akan terjadi, status tidak akan menunjukkan apa pun. Anda mengira Anda memiliki Konsul yang hidup, Anda bertanya, tetapi tidak terjadi apa-apa - tidak ada jawaban. Pada saat yang sama, statusnya menunjukkan bahwa semuanya baik-baik saja.
Kami mengalami masalah ini dan harus membangun kembali bagian tertentu dari pusat data untuk menghindarinya.
Versi bisnis Consul Enterprise tidak memiliki beberapa kekurangan di atas. Ini memiliki banyak fungsi yang berguna: pemilihan pemilih, distribusi, penskalaan. Hanya ada satu “tetapi” – sistem perizinan untuk sistem terdistribusi sangat mahal.
Peretasan hidup: rm -rf /var/lib/consul - Obat segala penyakit agen. Jika ada yang tidak berhasil untuk Anda, hapus saja data Anda dan unduh data dari salinannya. Kemungkinan besar, Konsul akan bekerja.
SEBELUMNYA
Sekarang mari kita bicara tentang apa yang telah kita tambahkan ke Konsul.
adalah singkatan dari BackEndFkemarahanWsemua. Saya harus memberi nama produk tersebut entah bagaimana ketika saya membuat repositori untuk memasukkan tes pertama ke dalamnya. Nama ini tetap ada.
Templat aturan
Aturannya ditulis dalam sintaks iptables.
- -N SEBELUMNYA
- -P MASUKAN TURUN
- -A INPUT -m status—status TERKAIT, DIDIRIKAN -j TERIMA
- -A MASUK -i lo -j TERIMA
- -A MASUKAN -j SEBELUMNYA
Semuanya masuk ke rantai BEFW, kecuali ESTABLISHED, RELATED dan host lokal. Templatenya bisa apa saja, ini hanya contoh saja.
Apa manfaat BEFW?
Layanan
Kami memiliki layanan, selalu memiliki port, node yang menjalankannya. Dari node kami, kami dapat bertanya secara lokal kepada agen dan mengetahui bahwa kami memiliki semacam layanan. Anda juga dapat memberi tag.
Layanan apa pun yang berjalan dan terdaftar di Konsul berubah menjadi aturan iptables. Kami memiliki SSH - buka port 22. Skrip Bash sederhana: curl dan iptables, tidak ada lagi yang diperlukan.
Pelanggan
Bagaimana cara membuka akses tidak untuk semua orang, tetapi secara selektif? Tambahkan daftar IP ke penyimpanan KV berdasarkan nama layanan.
Misalnya, kami ingin semua orang di jaringan kesepuluh dapat mengakses layanan SSH_TCP_22. Tambahkan satu bidang TTL kecil? dan sekarang kami punya izin sementara, misalnya sehari.
Mengakses
Kami menghubungkan layanan dan klien: kami memiliki layanan, penyimpanan KV siap untuk masing-masing. Sekarang kami memberikan akses tidak kepada semua orang, tetapi secara selektif.
Kelompok
Jika kita menulis ribuan IP untuk akses setiap saat, kita akan lelah. Mari kita buat pengelompokan - subset terpisah di KV. Sebut saja Alias (atau grup) dan simpan grup di sana dengan prinsip yang sama.
Ayo terhubung: sekarang kita bisa membuka SSH tidak khusus untuk P2P, tapi untuk seluruh grup atau beberapa grup. Dengan cara yang sama, ada TTL - Anda dapat menambahkan ke grup dan menghapusnya dari grup untuk sementara.
Integrasi
Masalah kita adalah faktor manusia dan otomatisasi. Sejauh ini kami telah menyelesaikannya dengan cara ini.
Kami bekerja dengan Wayang, dan mentransfer segala sesuatu yang berhubungan dengan sistem (kode aplikasi) kepada mereka. Puppetdb (PostgreSQL biasa) menyimpan daftar layanan yang berjalan di sana, layanan tersebut dapat ditemukan berdasarkan jenis sumber daya. Di sana Anda bisa mengetahui siapa yang melamar di mana. Kami juga memiliki sistem permintaan tarik dan permintaan penggabungan untuk ini.
Kami menulis befw-sync, solusi sederhana yang membantu mentransfer data. Pertama, cookie sinkronisasi diakses oleh dolldb. API HTTP dikonfigurasi di sana: kami meminta layanan apa yang kami miliki, apa yang perlu dilakukan. Kemudian mereka mengajukan permintaan kepada Konsul.
Apakah ada integrasi? Ya: mereka menulis aturan dan mengizinkan Permintaan Tarik diterima. Apakah Anda memerlukan port tertentu atau menambahkan host ke grup tertentu? Tarik Permintaan, tinjau - tidak perlu lagi “Temukan 200 ACL lainnya dan coba lakukan sesuatu untuk mengatasinya.”
Optimasi
Melakukan ping ke localhost dengan rantai aturan kosong membutuhkan waktu 0,075 ms.
Mari tambahkan 10 alamat iptables ke rantai ini. Hasilnya, ping akan meningkat 000 kali lipat: iptables sepenuhnya linier, pemrosesan setiap alamat memerlukan waktu.
Untuk firewall tempat kami memigrasikan ribuan ACL, kami memiliki banyak aturan, dan ini menimbulkan latensi. Ini buruk untuk protokol game.
Tapi jika kita taruh 10 alamat di ipset Pingnya malah akan berkurang.
Intinya “O” (kompleksitas algoritma) untuk ipset selalu sama dengan 1, tidak peduli berapa banyak aturan yang ada. Benar, ada batasan - aturan tidak boleh lebih dari 65535. Untuk saat ini kita hidup dengan ini: Anda dapat menggabungkannya, memperluasnya, membuat dua ipset menjadi satu.
Penyimpanan
Kelanjutan logis dari proses iterasi adalah menyimpan informasi tentang klien untuk layanan di ipset.
Sekarang kita memiliki SSH yang sama, dan kita tidak menulis 100 IP sekaligus, tetapi menetapkan nama ipset yang kita perlukan untuk berkomunikasi, dan aturan berikut DROP. Bisa diubah menjadi satu aturan “Siapa yang tidak ada di sini, DROP”, tapi lebih jelas.
Sekarang kami memiliki aturan dan perangkat. Tugas utamanya adalah membuat satu set sebelum menulis aturan, karena jika tidak, iptables tidak akan menulis aturan tersebut.
Skema umum
Dalam bentuk diagram, semua yang saya katakan terlihat seperti ini.
Kami berkomitmen pada Wayang, semuanya dikirim ke host, layanan di sini, ipset di sana, dan siapa pun yang tidak terdaftar di sana tidak diperbolehkan.
Memungkinkan menyangkal
Untuk menyelamatkan dunia dengan cepat atau menonaktifkan seseorang dengan cepat, di awal semua rantai kami membuat dua ipset: rules_allow и rules_deny. Bagaimana itu bekerja?
Misalnya, seseorang membuat beban di Web kita dengan bot. Sebelumnya, Anda harus menemukan IP-nya dari log, membawanya ke teknisi jaringan, sehingga mereka dapat menemukan sumber lalu lintas dan melarangnya. Sekarang terlihat berbeda.
Kita kirimkan ke Konsul, tunggu 2,5 detik, dan selesai. Karena Konsul mendistribusikan dengan cepat melalui P2P, ia berfungsi di mana saja, di belahan dunia mana pun.
Suatu ketika saya benar-benar menghentikan WOT karena kesalahan dengan firewall. rules_allow - ini adalah asuransi kami terhadap kasus seperti itu. Jika kami membuat kesalahan di suatu tempat dengan firewall, ada sesuatu yang diblokir di suatu tempat, kami selalu dapat mengirimkan persyaratan 0.0/0untuk segera mengambil semuanya. Nanti kami akan memperbaiki semuanya dengan tangan.
Set lainnya
Anda dapat menambahkan set lainnya di luar angkasa $IPSETS$.
Untuk apa? Terkadang seseorang membutuhkan ipset, misalnya, untuk meniru penutupan beberapa bagian cluster. Siapapun boleh membawa set apa saja, beri nama, dan akan diambil dari Konsul. Pada saat yang sama, set dapat berpartisipasi dalam aturan iptables atau bertindak sebagai sebuah tim NOOP: Konsistensi akan dipertahankan oleh daemon.
Anggota
Sebelumnya seperti ini: pengguna terhubung ke jaringan dan menerima parameter melalui domain. Sebelum munculnya firewall generasi baru, Cisco tidak tahu bagaimana memahami di mana pengguna berada dan di mana IP berada. Oleh karena itu, akses hanya diberikan melalui nama host mesin.
Apa yang telah kita lakukan? Kami terjebak saat kami menerima alamatnya. Biasanya ini dot1x, Wi-Fi atau VPN - semuanya melalui RADIUS. Untuk setiap pengguna, kami membuat grup berdasarkan nama pengguna dan menempatkan IP di dalamnya dengan TTL yang sama dengan dhcp.lease - segera setelah habis masa berlakunya, aturan tersebut akan hilang.
Sekarang kita dapat membuka akses ke layanan, seperti grup lain, berdasarkan nama pengguna. Kami telah menghilangkan rasa sakit dari nama host ketika mereka berubah, dan kami telah meringankan beban para insinyur jaringan karena mereka tidak lagi membutuhkan Cisco. Sekarang para insinyur sendiri yang mendaftarkan akses ke server mereka.
Isolasi
Pada saat yang sama, kami mulai membongkar insulasi. Manajer layanan melakukan inventarisasi, dan kami menganalisis semua jaringan kami. Mari kita bagi mereka ke dalam grup yang sama, dan di server yang diperlukan grup tersebut ditambahkan, misalnya, untuk menolak. Sekarang isolasi pementasan yang sama berakhir di rule_deny produksi, tetapi tidak di produksi itu sendiri.
Skema ini bekerja dengan cepat dan sederhana: kami menghapus semua ACL dari server, membongkar perangkat keras, dan mengurangi jumlah VLAN yang terisolasi.
Kontrol integritas
Sebelumnya, kami memiliki pemicu khusus yang melaporkan ketika seseorang mengubah aturan firewall secara manual. Saya sedang menulis linter besar untuk memeriksa aturan firewall, itu sulit. Integritas kini dikendalikan oleh BEFW. Ia dengan penuh semangat memastikan bahwa aturan yang dibuatnya tidak berubah. Jika seseorang mengubah aturan firewall, semuanya akan berubah kembali. “Saya segera menyiapkan proxy sehingga saya dapat bekerja dari rumah”—tidak ada lagi pilihan seperti itu.
BEFW mengontrol ipset dari layanan dan mencantumkan di befw.conf, aturan layanan dalam rantai BEFW. Tapi itu tidak memantau rantai dan aturan lain serta ipset lainnya.
Perlindungan terhadap kecelakaan
BEFW selalu menyimpan status baik terakhir yang diketahui secara langsung dalam struktur biner state.bin. Jika terjadi kesalahan, selalu kembali ke state.bin ini.
Hal ini merupakan jaminan terhadap ketidakstabilan operasional Konsul, ketika tidak mengirimkan data atau ada yang melakukan kesalahan dan menggunakan aturan yang tidak dapat diterapkan. Untuk memastikan bahwa kita tidak dibiarkan tanpa firewall, BEFW akan mengembalikan ke status terbaru jika terjadi kesalahan pada tahap apa pun.
Dalam situasi kritis, ini adalah jaminan bahwa firewall kita akan berfungsi. Kami membuka semua jaringan abu-abu dengan harapan admin akan datang dan memperbaikinya. Suatu hari nanti saya akan memasukkan ini ke dalam konfigurasi, tetapi sekarang kami hanya memiliki tiga jaringan abu-abu: 10/8, 172/12 dan 192.168/16. Di dalam Konsul kami, ini adalah fitur penting yang membantu kami berkembang lebih jauh.
Demo: selama laporan, Ivan mendemonstrasikan mode demo BEFW. Lebih mudah untuk menonton demonstrasi . Kode sumber demo tersedia .
Jebakan
Saya akan memberi tahu Anda tentang bug yang kami temui.
ipset tambahkan set 0.0.0.0/0. Apa yang terjadi jika Anda menambahkan 0.0.0.0/0 ke ipset? Apakah semua IP akan ditambahkan? Apakah akses Internet akan tersedia?
Tidak, kami akan mendapatkan bug yang membuat kami kehilangan waktu henti selama dua jam. Selain itu, bug tersebut tidak berfungsi sejak tahun 2016, bug tersebut terletak di RedHat Bugzilla dengan nomor #1297092, dan kami menemukannya secara tidak sengaja - dari laporan pengembang.
Sekarang menjadi aturan ketat di BEFW 0.0.0.0/0 berubah menjadi dua alamat: 0.0.0.0/1 и 128.0.0.0/1.
ipset memulihkan set <file. Apa yang dilakukan ipset ketika Anda menyuruhnya restore? Apakah menurut Anda cara kerjanya sama dengan iptables? Apakah ini akan memulihkan data?
Tidak seperti itu - ia menggabungkan, dan alamat lama tidak kemana-mana, Anda tidak memblokir akses.
Kami menemukan bug saat menguji isolasi. Sekarang ada sistem yang agak rumit - sebagai gantinya restore diadakan create temp, lalu restore flush temp и restore temp. Di akhir pertukaran: untuk atomisitas, karena jika Anda melakukannya terlebih dahulu flush dan saat ini beberapa paket tiba, paket itu akan dibuang dan ada yang tidak beres. Jadi ada sedikit ilmu hitam di sana.
konsul kv get -datacenter=other. Seperti yang saya katakan, kami pikir kami meminta beberapa data, tetapi kami akan mendapatkan data atau kesalahan. Kita dapat melakukan ini melalui Konsul secara lokal, namun dalam kasus ini keduanya akan dibekukan.
Klien Konsul lokal adalah pembungkus HTTP API. Tapi itu hanya hang dan tidak merespon Ctrl+C, atau Ctrl+Z, atau apa pun saja kill -9 di konsol berikutnya. Kami mengalami hal ini ketika kami sedang membangun cluster besar. Namun kami belum mempunyai solusinya, kami sedang bersiap untuk memperbaiki kesalahan ini di Konsul.
Pemimpin konsul tidak menanggapi. Master kami di pusat data tidak merespons, kami berpikir: “Mungkin algoritme pemilihan ulang akan berfungsi sekarang?”
Tidak, tidak akan berhasil, dan pemantauan tidak akan menunjukkan apa-apa: Konsul akan mengatakan bahwa ada indeks komitmen, pemimpin sudah ditemukan, semuanya baik-baik saja.
Bagaimana kita menghadapinya? service consul restart di cron setiap jam. Jika Anda memiliki 50 server, bukan masalah besar. Jika jumlahnya 16, Anda akan memahami cara kerjanya.
Kesimpulan
Hasilnya, kami menerima keuntungan sebagai berikut:
- Cakupan 100% dari semua mesin Linux.
- Kecepatan
- Otomatisasi.
- Kami membebaskan insinyur perangkat keras dan jaringan dari perbudakan.
- Kemungkinan integrasi yang hampir tak terbatas telah muncul: bahkan dengan Kubernetes, bahkan dengan Ansible, bahkan dengan Python.
Kontra: Konsul, dengan siapa kita sekarang harus hidup, dan biaya kesalahan yang sangat tinggi. Sebagai contoh, suatu saat pada jam 6 sore (jam tayang utama di Rusia) saya sedang mengedit sesuatu di daftar jaringan. Kami baru saja membangun isolasi di BEFW saat itu. Saya membuat kesalahan di suatu tempat, sepertinya saya menunjukkan topeng yang salah, tetapi semuanya hilang dalam dua detik. Monitor menyala, petugas pendukung yang bertugas berlari: “Kami memiliki segalanya!” Kepala departemen menjadi abu-abu ketika dia menjelaskan kepada bisnis mengapa hal ini terjadi.
Kerugian akibat kesalahan begitu tinggi sehingga kita harus mempunyai prosedur pencegahan yang rumit. Jika Anda menerapkan ini di situs produksi besar, Anda tidak perlu memberikan token master melalui Konsul kepada semua orang. Ini akan berakhir buruk.
Biaya. Saya menulis kode selama 400 jam saja. Tim saya yang terdiri dari 4 orang menghabiskan 10 jam sebulan untuk mendukung semua orang. Dibandingkan dengan harga firewall generasi baru, ini gratis.
Rencana. Rencana jangka panjangnya adalah mencari alternatif transportasi untuk menggantikan atau melengkapi Konsul. Mungkin Kafka atau yang serupa. Namun di tahun-tahun mendatang kami akan tinggal di Konsul.
Rencana segera: integrasi dengan Fail2ban, dengan pemantauan, dengan nftables, mungkin dengan distribusi lain, metrik, pemantauan lanjutan, pengoptimalan. Dukungan Kubernetes juga ada dalam rencana, karena sekarang kami memiliki beberapa cluster dan keinginan tersebut.
Lebih banyak dari rencana:
- mencari anomali lalu lintas;
- manajemen peta jaringan;
- dukungan Kubernetes;
- merakit paket untuk semua sistem;
- UI Web.
Kami terus berupaya memperluas konfigurasi, meningkatkan metrik, dan pengoptimalan.
Bergabunglah dengan proyek ini. Proyeknya ternyata keren, tapi sayangnya masih proyek satu orang. Datang ke dan mencoba melakukan sesuatu: melakukan, menguji, menyarankan sesuatu, memberikan penilaian Anda.
Sementara itu kami sedang mempersiapkannya , yang akan berlangsung pada tanggal 6 dan 7 April di St. Petersburg, dan kami mengundang pengembang sistem beban tinggi . Pembicara berpengalaman sudah tahu apa yang harus dilakukan, tapi bagi mereka yang baru berbicara, kami merekomendasikan setidaknya . Berpartisipasi dalam konferensi sebagai pembicara memiliki sejumlah keuntungan. Anda bisa membaca yang mana, misalnya di bagian akhir .
Sumber: www.habr.com