Mengapa kami membuatnya?
Untuk waktu yang lama, kami di Rambler Group telah menggunakan arsitektur jaringan pusat data tiga tingkat, di mana setiap komponen proyek atau infrastruktur berada dalam vlan khusus. Semua lalu lintas - baik antar van dan antar pusat data - melewati peralatan tingkat tepi.
Peralatan edge adalah router mahal yang mampu melakukan banyak fungsi berbeda, oleh karena itu port di atasnya juga mahal. Seiring waktu, lalu lintas horizontal tumbuh (mesin-ke-mesin - misalnya, replikasi database, permintaan ke berbagai layanan, dll.), Dan di beberapa titik muncul masalah pemanfaatan port pada router perbatasan.
Salah satu fungsi utama perangkat tersebut adalah pemfilteran lalu lintas. Akibatnya, pengelolaan ACL juga menjadi lebih sulit: Anda harus melakukan semuanya secara manual, ditambah lagi pelaksanaan tugas oleh departemen yang berdekatan juga membutuhkan waktu. Waktu tambahan dihabiskan untuk mengkonfigurasi port di tingkat Access. Itu perlu untuk melakukan tidak hanya tindakan manual dari NOC yang sama, tetapi juga untuk mengidentifikasi masalah keamanan potensial, karena tuan rumah mengubah lokasi mereka, masing-masing, mereka bisa mendapatkan akses tidak sah ke van orang lain.
Waktunya telah tiba untuk mengubah sesuatu, dan jaringan Clos atau, sebagaimana mereka juga disebut, pabrik IP datang untuk menyelamatkan.
Terlepas dari kesamaan eksternal, perbedaan mendasar antara arsitektur ini dan yang sebelumnya adalah setiap perangkat, termasuk lapisan daun, bertindak sebagai router, dan gateway default untuk server adalah Top-of-Rack. Dengan demikian, lalu lintas horizontal antara host mana pun dari proyek yang berbeda sekarang dapat melalui lapisan tulang belakang, dan tidak melalui tepi.
Selain itu, pada tingkat tulang belakang yang sama, kami dapat menghubungkan pusat data satu sama lain, dan tidak lebih dari empat perangkat jaringan sekarang terletak di jalur antara dua server mana pun. Peralatan edge dalam arsitektur ini hanya diperlukan untuk menghubungkan operator telekomunikasi dan hanya memungkinkan lalu lintas vertikal (ke dan dari Internet).
Fitur utama dari jaringan Klose adalah ia tidak memiliki tempat di mana Anda dapat memfilter lalu lintas antar host. Oleh karena itu, fungsi ini harus dijalankan langsung di server. Firewall terpusat adalah program yang memfilter lalu lintas pada host itu sendiri yang menerima lalu lintas.
Persyaratan
Kebutuhan untuk mengimplementasikan firewall terpusat ditentukan oleh beberapa faktor sekaligus:
- konsumen akhir dan
- infrastruktur yang ada.
Oleh karena itu, persyaratan untuk aplikasi tersebut adalah sebagai berikut:
- Firewall harus dapat bekerja dan membuat aturan pada host dan mesin virtual. Selain itu, daftar aturan tidak boleh berbeda dari lingkungan tempat firewall dijalankan. Artinya, aturannya identik.
- . , – ssh, ( Prometheus), .
- , -.
- , – .
- .
- : « , ».
Cloud Rambler Group cukup dinamis: mesin virtual dibuat dan dihapus, server dipasang dan dibongkar. Oleh karena itu, kami tidak menggunakan akses point-to-point, infrastruktur kami memiliki konsep “host group”.
Hostgroup adalah markup dari sekelompok server yang secara unik menjelaskan peran mereka. Misalnya news-prod-coolstream-blue.
Ini mengarah ke persyaratan lain: pengguna harus beroperasi dengan entitas tingkat tinggi - grup host, proyek, dan sebagainya.
Ide dan implementasi
Tulling
Firewall terpusat adalah hal yang besar dan kompleks yang memerlukan konfigurasi agen. Menemukan masalah dapat memakan waktu lebih dari lima menit, sehingga alat muncul bersama agen dan server, yang memberi tahu pengguna jika agen dikonfigurasi dengan benar dan apa yang perlu diperbaiki. Misalnya, persyaratan penting untuk host adalah keberadaan data DNS di hostgroup atau PTR. Alat ini akan memberi tahu Anda tentang semua ini dan banyak lagi ( fungsinya dijelaskan di bawah ).
Firewall terpadu
Kami mencoba untuk mengikuti prinsip berikut: aplikasi yang mengkonfigurasi firewall pada host harus menjadi satu-satunya agar tidak mendapatkan "aturan berkedip". Artinya, jika server sudah memiliki alat kustomisasi sendiri (misalnya, jika aturan dikonfigurasi oleh agen lain), maka aplikasi kita tidak termasuk di sana. Nah, kondisi sebaliknya juga berfungsi: jika ada agen firewall kami, maka hanya dia yang menetapkan aturan - inilah prinsip kontrol total.
Firewall bukan iptables
Seperti yang Anda ketahui, iptables hanyalah utilitas baris perintah untuk bekerja dengan netfilter. Untuk mem-port firewall ke platform yang berbeda (Windows, sistem BSD), agen dan server bekerja dengan model mereka sendiri. Lebih lanjut tentang ini di bawah, di bagian "Arsitektur" .
Agen tidak mencoba menyelesaikan kesalahan logika
Sebagaimana dinyatakan di atas, agen tidak mengambil keputusan apa pun. Jika Anda ingin menutup port 443, di mana server HTTP Anda sudah berjalan, tidak masalah, tutuplah!
Arsitektur
Sulit untuk menghasilkan sesuatu yang baru dalam arsitektur aplikasi semacam itu.
- Kami memiliki agen, dia mengonfigurasi aturan pada tuan rumah.
- Kami memiliki server, ini memberikan aturan yang ditentukan pengguna.
- Kami memiliki perpustakaan dan alat.
- Kami memiliki resolver tingkat tinggi - ini mengubah alamat ip menjadi grup host / proyek dan sebaliknya. Lebih lanjut tentang semua ini di bawah .
Rambler Group memiliki banyak host dan bahkan lebih banyak mesin virtual, dan semuanya, dalam satu atau lain cara, termasuk dalam beberapa entitas:
- VLAN
- Jaringan
- Proyek
- Grup tuan rumah.
Yang terakhir menjelaskan milik tuan rumah ke proyek dan perannya. Misalnya, news-prod-backend-api, di mana: news - project; prod - its env, dalam hal ini produksi; backend - peran; api adalah tag kustom arbitrer.
Resolver
Firewall bekerja di jaringan dan / atau tingkat transportasi, dan grup host serta proyek adalah entitas tingkat tinggi. Oleh karena itu, untuk "berteman" dan memahami siapa yang memiliki host (atau mesin virtual), Anda perlu mendapatkan daftar alamat - kami menamakan komponen ini "Pemecah Tingkat Tinggi". Ini mengubah nama tingkat tinggi menjadi satu set alamat (dalam hal resolver itu "berisi") dan, sebaliknya, alamat ke nama entitas ("berisi").
Library - Core
Untuk unifikasi dan unifikasi beberapa komponen, muncul library yang disebut juga Core. Ini adalah model data dengan pengontrol dan tampilan sendiri yang memungkinkan Anda untuk mengisi dan membacanya. Pendekatan ini sangat menyederhanakan sisi server dan kode agen, dan juga membantu membandingkan aturan saat ini di host dengan aturan yang diterima dari server.
Kami memiliki beberapa sumber untuk mengisi model:
- file aturan (dua jenis berbeda: disederhanakan dan menjelaskan aturan sepenuhnya)
- aturan yang diterima dari server
- aturan yang diterima dari tuan rumah sendiri.
Agent
Agent bukan pengikatan iptables, tetapi aplikasi independen yang bekerja menggunakan pembungkus di atas library C libiptc, libxtables. Agen itu sendiri tidak membuat keputusan apa pun, tetapi hanya mengonfigurasi aturan di host.
Peran agen minimal: baca file aturan (termasuk yang default), dapatkan data dari server (jika dikonfigurasi untuk operasi jarak jauh), gabungkan aturan menjadi satu set, periksa apakah berbeda dari status sebelumnya, dan, jika berbeda, terapkan.
Peran penting lain dari agen adalah tidak mengubah host menjadi labu selama penginstalan awal atau saat menerima respons tidak valid dari server. Untuk menghindari hal ini, kami menyediakan sekumpulan aturan dalam paket secara default, seperti ssh, akses pemantauan, dan sebagainya. Jika agen firewall menerima kode respons selain kode respons ke-200, agen tidak akan mencoba melakukan tindakan apa pun dan akan meninggalkan status sebelumnya. Tetapi itu tidak melindungi dari kesalahan logis, jika Anda menolak akses pada port 80, 443, maka agen akan tetap melakukan tugasnya, bahkan ketika layanan web berjalan di host.
Tulza
Tulza ditujukan untuk administrator sistem dan pengembang yang memelihara proyek. Tujuannya sangat sederhana: dengan satu klik, dapatkan semua data tentang pekerjaan agen. Utilitas dapat memberi tahu Anda tentang:
- adalah daemon agen sedang berjalan
- apakah ada data PTR untuk tuan rumah
- .
Informasi ini cukup untuk mendiagnosis masalah pada tahap awal.
Server
Server adalah aplikasi + database. Semua logika pekerjaan dilakukan olehnya. Fitur penting dari server adalah tidak menyimpan alamat IP. Server hanya bekerja dengan objek tingkat atas - nama grup host, proyek, dll.
Aturan dasar adalah sebagai berikut: Tindakan: Terima Src: project-B, project-C Dst: Project-B Proto: tcp Ports: 80, 443.
Bagaimana server memahami aturan mana yang harus diberikan dan kepada siapa? Ini mengikuti dari persyaratan bahwa aturan harus identik di mana pun agen berjalan, baik itu host atau mesin virtual.
Permintaan dari agen selalu datang ke server dengan satu nilai - alamat IP. Penting untuk diingat bahwa setiap agen meminta aturan untuk dirinya sendiri, yaitu dialah tujuan.
Untuk memudahkan pemahaman tentang operasi server, pertimbangkan proses untuk mendapatkan aturan host yang dimiliki sebuah proyek.
Penyelesai mulai bermain terlebih dahulu. Tugasnya adalah mengubah alamat IP menjadi nama host, dan kemudian mencari tahu di entitas mana host ini berada. HL-Resolver membalas ke server bahwa tuan rumah terdapat dalam proyek A. HL-Resolver mengacu pada Sumber Data (yang belum kami sebutkan sebelumnya). Sumber data adalah sejenis basis pengetahuan perusahaan tentang server, proyek, grup host, dll.
Selanjutnya, server mencari semua aturan untuk proyek dengan tujuan = nama proyek. Karena kita tidak mengandung alamat dalam database, kita perlu mengganti nama proyek menjadi hostenyms, dan kemudian menjadi alamat, sehingga permintaan dikirim lagi ke Sumber Data melalui resolver. HL-Resoler mengembalikan daftar alamat, setelah itu agen menerima daftar aturan yang sudah jadi.
Jika tujuan kita adalah host dengan mesin virtual, maka skrip yang sama dijalankan tidak hanya untuk host, tetapi juga untuk setiap mesin virtual di dalamnya.
Di bawah ini adalah diagram yang menunjukkan kasus sederhana: host (perangkat keras atau mesin virtual) menerima aturan untuk host di Proyek-A.
Rilis
Tidak sulit untuk menebak bahwa memiliki manajemen firewall terpusat, Anda juga dapat merusak semuanya secara terpusat. Oleh karena itu, rilis untuk agen dan server dilakukan secara bertahap.
Untuk server - Pengujian Biru-Hijau + A / B
Biru-Hijau adalah strategi penyebaran yang melibatkan dua grup host. Dan peralihan berlangsung dalam porsi 1,3,5,10 ... 100%. jadi jika ada masalah dengan rilis baru, hanya sebagian kecil layanan yang akan menderita.
Untuk agen, Canary
Canary (atau penerapan canary) agak mirip dengan pengujian A / B. Kami hanya memperbarui beberapa agen dan melihat metrik. Jika semuanya baik-baik saja, kami mengambil potongan yang lebih besar dan seterusnya hingga 100%.
Kesimpulan
Hasilnya, kami membuat layanan mandiri untuk teknisi sistem, yang memungkinkan Anda mengelola akses jaringan dari satu titik. Jadi, kami:
- HTTP-API
- .