Bagaimana mengendalikan infrastruktur jaringan Anda. Bab tiga. Keamanan jaringan. Bagian kedua

Artikel ini adalah bagian keempat dari seri “Cara Mengendalikan Infrastruktur Jaringan Anda.” Isi semua artikel dalam seri dan tautan dapat ditemukan di sini.

В bagian pertama Pada bab ini, kita melihat beberapa aspek keamanan jaringan di segmen Pusat Data. Bagian ini akan dikhususkan untuk segmen “Akses Internet”.

Bagaimana mengendalikan infrastruktur jaringan Anda. Bab tiga. Keamanan jaringan. Bagian kedua

Akses Internet

Topik keamanan tidak diragukan lagi merupakan salah satu topik paling kompleks di dunia jaringan data. Seperti dalam kasus-kasus sebelumnya, tanpa berpura-pura mendalam dan lengkap, di sini saya akan membahas pertanyaan-pertanyaan yang cukup sederhana, namun menurut saya penting, yang jawabannya saya harap dapat membantu meningkatkan tingkat keamanan jaringan Anda.

Saat mengaudit segmen ini, perhatikan aspek-aspek berikut:

  • disain
  • Pengaturan BGP
  • Perlindungan DOS/DDOS
  • penyaringan lalu lintas di firewall

Disain

Sebagai contoh desain segmen ini untuk jaringan perusahaan, saya akan merekomendasikannya panduan dari Cisco di dalamnya Model AMAN.

Tentu saja, mungkin solusi dari vendor lain akan tampak lebih menarik bagi Anda (lihat. Kuadran Gartner 2018), namun tanpa mendorong Anda untuk mengikuti desain ini secara mendetail, saya tetap merasa berguna untuk memahami prinsip dan ide di baliknya.

Catatan

Di SAFE, segmen "Akses Jarak Jauh" adalah bagian dari segmen "Akses Internet". Namun dalam rangkaian artikel ini kami akan membahasnya secara terpisah.

Kumpulan peralatan standar di segmen ini untuk jaringan perusahaan adalah

  • router perbatasan
  • firewall

Catatan 1

Dalam rangkaian artikel ini, ketika saya berbicara tentang firewall, maksud saya NGFW.

Catatan 2

Saya mengabaikan pertimbangan berbagai jenis solusi L2/L1 atau overlay L2 di atas L3 yang diperlukan untuk memastikan konektivitas L1/L2 dan membatasi diri saya hanya pada masalah di level L3 dan di atasnya. Secara parsial permasalahan L1/L2 dibahas pada bab “Pembersihan dan Dokumentasi".

Jika Anda belum menemukan firewall di segmen ini, maka sebaiknya jangan terburu-buru mengambil kesimpulan.

Mari kita lakukan hal yang sama seperti di bagian sebelumnyaMari kita mulai dengan pertanyaan: apakah dalam kasus Anda perlu menggunakan firewall di segmen ini?

Saya dapat mengatakan bahwa ini tampaknya menjadi tempat yang paling tepat untuk menggunakan firewall dan menerapkan algoritma penyaringan lalu lintas yang kompleks. DI DALAM 1 bagian Kami menyebutkan 4 faktor yang dapat mengganggu penggunaan firewall di segmen pusat data. Tapi di sini mereka tidak lagi begitu penting.

Contoh 1. Keterlambatan

Sejauh menyangkut Internet, tidak ada gunanya membicarakan penundaan bahkan sekitar 1 milidetik. Oleh karena itu, penundaan pada segmen ini tidak dapat menjadi faktor yang membatasi penggunaan firewall.

Contoh 2. Performa

Dalam beberapa kasus, faktor ini mungkin masih penting. Oleh karena itu, Anda mungkin harus mengizinkan beberapa lalu lintas (misalnya, lalu lintas dari penyeimbang beban) untuk melewati firewall.

Contoh 3. Keandalan

Faktor ini masih perlu diperhitungkan, namun mengingat tidak dapat diandalkannya Internet itu sendiri, kepentingannya bagi segmen ini tidak sepenting bagi pusat data.

Jadi, anggaplah layanan Anda ada di atas http/https (dengan sesi singkat). Dalam hal ini, Anda dapat menggunakan dua kotak independen (tanpa HA) dan jika ada masalah perutean dengan salah satunya, transfer semua lalu lintas ke kotak kedua.

Atau Anda dapat menggunakan firewall dalam mode transparan dan, jika gagal, izinkan lalu lintas melewati firewall sambil menyelesaikan masalah.

Oleh karena itu, kemungkinan besar saja harga mungkin menjadi faktor yang memaksa Anda untuk meninggalkan penggunaan firewall di segmen ini.

Penting!

Ada godaan untuk menggabungkan firewall ini dengan firewall pusat data (gunakan satu firewall untuk segmen ini). Solusinya, pada prinsipnya, mungkin, tetapi Anda perlu memahaminya karena Firewall Akses Internet sebenarnya berada di garis depan pertahanan Anda dan “menghadapi” setidaknya sebagian lalu lintas berbahaya, maka, tentu saja, Anda perlu memperhitungkan peningkatan risiko bahwa firewall ini akan dinonaktifkan. Artinya, dengan menggunakan perangkat yang sama di dua segmen tersebut, Anda akan mengurangi ketersediaan segmen pusat data Anda secara signifikan.

Seperti biasa, Anda perlu memahami bahwa tergantung pada layanan yang disediakan perusahaan, desain segmen ini mungkin sangat bervariasi. Seperti biasa, Anda dapat memilih pendekatan yang berbeda tergantung pada kebutuhan Anda.

Contoh

Jika Anda adalah penyedia konten, dengan jaringan CDN (lihat, misalnya, serangkaian artikel), maka Anda mungkin tidak ingin membuat infrastruktur di lusinan atau bahkan ratusan titik kehadiran menggunakan perangkat terpisah untuk merutekan dan memfilter lalu lintas. Ini akan mahal, dan mungkin tidak diperlukan.

Untuk BGP Anda tidak harus memiliki router khusus, Anda dapat menggunakan alat sumber terbuka seperti Quagga. Jadi mungkin yang Anda butuhkan hanyalah sebuah server atau beberapa server, sebuah switch dan BGP.

Dalam hal ini, server Anda atau beberapa server tidak hanya dapat berperan sebagai server CDN, tetapi juga sebagai router. Tentu saja, masih banyak rinciannya (seperti bagaimana memastikan keseimbangan), namun hal ini dapat dilakukan, dan ini adalah pendekatan yang berhasil kami gunakan untuk salah satu mitra kami.

Anda dapat memiliki beberapa pusat data dengan perlindungan penuh (firewall, layanan perlindungan DDOS yang disediakan oleh penyedia Internet Anda) dan lusinan atau ratusan titik kehadiran yang “disederhanakan” hanya dengan sakelar dan server L2.

Namun bagaimana dengan perlindungan dalam kasus ini?

Mari kita lihat, misalnya, yang baru-baru ini populer Serangan DDOS Amplifikasi DNS. Bahayanya terletak pada kenyataan bahwa sejumlah besar lalu lintas dihasilkan, yang hanya “menyumbat” 100% dari semua uplink Anda.

Apa yang kita miliki dalam kasus desain kita.

  • jika Anda menggunakan AnyCast, lalu lintas didistribusikan di antara titik kehadiran Anda. Jika total bandwidth Anda adalah terabit, maka ini sebenarnya (namun, baru-baru ini ada beberapa serangan dengan lalu lintas berbahaya dalam urutan terabit) melindungi Anda dari uplink yang “meluap”
  • Namun, jika beberapa uplink tersumbat, Anda cukup menghapus situs ini dari layanan (berhenti mengiklankan awalan)
  • Anda juga dapat meningkatkan porsi lalu lintas yang dikirim dari pusat data “penuh” (dan karenanya terlindungi), sehingga menghilangkan sebagian besar lalu lintas berbahaya dari titik keberadaan yang tidak terlindungi

Dan satu lagi catatan kecil untuk contoh ini. Jika Anda mengirimkan lalu lintas yang cukup melalui IX, ini juga mengurangi kerentanan Anda terhadap serangan tersebut

Menyiapkan BGP

Ada dua topik di sini.

  • Konektivitas
  • Menyiapkan BGP

Kami telah berbicara sedikit tentang konektivitas 1 bagian. Intinya adalah memastikan lalu lintas ke pelanggan Anda mengikuti jalur yang optimal. Meskipun optimalitas tidak selalu hanya tentang latensi, latensi rendah biasanya merupakan indikator utama optimalitas. Bagi beberapa perusahaan, hal ini lebih penting, namun bagi perusahaan lain kurang penting. Itu semua tergantung pada layanan yang Anda berikan.

misalnya 1

Jika Anda seorang bursa, dan interval waktu kurang dari milidetik penting bagi klien Anda, tentu saja, tidak ada pembicaraan tentang Internet apa pun sama sekali.

misalnya 2

Jika Anda adalah perusahaan game dan puluhan milidetik penting bagi Anda, tentu saja konektivitas sangat penting bagi Anda.

misalnya 3

Perlu Anda pahami juga bahwa, karena sifat protokol TCP, kecepatan transfer data dalam satu sesi TCP juga bergantung pada RTT (Round Trip Time). Jaringan CDN juga sedang dibangun untuk mengatasi masalah ini dengan mendekatkan server distribusi konten ke konsumen konten tersebut.

Studi tentang konektivitas merupakan topik yang menarik, layak untuk dijadikan artikel atau seri artikel tersendiri, dan memerlukan pemahaman yang baik tentang cara kerja Internet.

Sumber daya yang berguna:

ripe.net
bgp.he.net

Contoh

Saya akan memberikan satu contoh kecil saja.

Misalkan pusat data Anda berlokasi di Moskow, dan Anda memiliki satu uplink - Rostelecom (AS12389). Dalam hal ini (rumah tunggal) Anda tidak memerlukan BGP, dan kemungkinan besar Anda menggunakan kumpulan alamat dari Rostelecom sebagai alamat publik.

Misalkan Anda menyediakan layanan tertentu, dan Anda memiliki cukup banyak klien dari Ukraina, dan mereka mengeluh tentang penundaan yang lama. Selama penelitian Anda, Anda menemukan bahwa alamat IP beberapa di antaranya berada di grid 37.52.0.0/21.

Dengan menjalankan traceroute, Anda melihat bahwa lalu lintas melewati AS1299 (Telia), dan dengan menjalankan ping, Anda mendapatkan RTT rata-rata 70 - 80 milidetik. Anda juga dapat melihatnya di kaca tampak Rostelecom.

Menggunakan utilitas whois (di matang.net atau utilitas lokal), Anda dapat dengan mudah menentukan bahwa blok 37.52.0.0/21 milik AS6849 (Ukrtelecom).

Selanjutnya, dengan pergi ke bgp.he.net Anda melihat bahwa AS6849 tidak memiliki hubungan dengan AS12389 (mereka bukan klien atau uplink satu sama lain, juga tidak memiliki peering). Namun jika dilihat daftar rekan-rekan untuk AS6849, Anda akan melihat, misalnya, AS29226 (Mastertel) dan AS31133 (Megafon).

Setelah Anda menemukan gambaran penyedia ini, Anda dapat membandingkan jalur dan RTT. Misalnya, untuk Mastertel RTT akan berdurasi sekitar 30 milidetik.

Jadi, jika perbedaan antara 80 dan 30 milidetik signifikan untuk layanan Anda, maka mungkin Anda perlu memikirkan tentang konektivitas, mendapatkan nomor AS, kumpulan alamat Anda dari RIPE dan menghubungkan uplink tambahan dan/atau membuat titik kehadiran di IX.

Saat Anda menggunakan BGP, Anda tidak hanya memiliki kesempatan untuk meningkatkan konektivitas, namun Anda juga memelihara koneksi Internet Anda secara berlebihan.

Dokumen ini berisi rekomendasi untuk mengkonfigurasi BGP. Terlepas dari kenyataan bahwa rekomendasi ini dikembangkan berdasarkan “praktik terbaik” penyedia, namun (jika pengaturan BGP Anda tidak terlalu mendasar) rekomendasi tersebut tidak diragukan lagi berguna dan pada kenyataannya harus menjadi bagian dari pengerasan yang kita bahas di bagian pertama.

Perlindungan DOS/DDOS

Sekarang serangan DOS/DDOS telah menjadi kenyataan sehari-hari di banyak perusahaan. Faktanya, Anda cukup sering diserang dalam satu atau lain bentuk. Fakta bahwa Anda belum menyadarinya hanya berarti bahwa serangan yang ditargetkan belum diorganisir terhadap Anda, dan bahwa tindakan perlindungan yang Anda gunakan, bahkan mungkin tanpa menyadarinya (berbagai perlindungan bawaan sistem operasi), cukup untuk memastikan bahwa degradasi layanan yang diberikan diminimalkan untuk Anda dan klien Anda.

Ada sumber daya Internet yang, berdasarkan log peralatan, menggambar peta serangan yang indah secara real-time.

Di sini Anda dapat menemukan tautan ke sana.

Favorit saya peta dari Pos Pemeriksaan.

Perlindungan terhadap DDOS/DOS biasanya berlapis. Untuk memahami alasannya, Anda perlu memahami jenis serangan DOS/DDOS apa yang ada (lihat, misalnya, di sini или di sini)

Artinya, kami memiliki tiga jenis serangan:

  • serangan volumetrik
  • serangan protokol
  • serangan aplikasi

Jika Anda dapat melindungi diri Anda dari dua jenis serangan terakhir dengan menggunakan, misalnya, firewall, maka Anda tidak dapat melindungi diri Anda dari serangan yang ditujukan untuk “membanjiri” uplink Anda (tentu saja, jika total kapasitas saluran Internet Anda tidak dihitung dalam terabit, atau lebih baik lagi, dalam puluhan terabit).

Oleh karena itu, garis pertahanan pertama adalah perlindungan terhadap serangan “volumetrik”, dan penyedia layanan Anda harus memberikan perlindungan ini kepada Anda. Jika Anda belum menyadarinya, maka Anda beruntung untuk saat ini.

Contoh

Katakanlah Anda memiliki beberapa uplink, namun hanya satu penyedia yang dapat memberi Anda perlindungan ini. Namun jika semua trafik melewati satu penyedia, lalu bagaimana dengan konektivitas yang telah kita bahas secara singkat tadi?

Dalam hal ini, Anda harus mengorbankan sebagian konektivitas selama serangan. Tetapi

  • ini hanya selama durasi serangan. Jika terjadi serangan, Anda dapat mengkonfigurasi ulang BGP secara manual atau otomatis sehingga lalu lintas hanya melewati penyedia yang memberi Anda “payung”. Setelah serangan selesai, Anda dapat mengembalikan perutean ke kondisi sebelumnya
  • Tidak perlu mentransfer semua lalu lintas. Jika, misalnya, Anda melihat tidak ada serangan melalui beberapa uplink atau peering (atau lalu lintasnya tidak signifikan), Anda dapat terus mengiklankan awalan dengan atribut kompetitif terhadap tetangga BGP ini.

Anda juga dapat mendelegasikan perlindungan dari “serangan protokol” dan “serangan aplikasi” kepada mitra Anda.
di sini adalah di sini Anda dapat membaca studi yang bagus (terjemahan). Benar, artikel ini berumur dua tahun, tetapi artikel ini akan memberi Anda gambaran tentang pendekatan bagaimana Anda dapat melindungi diri dari serangan DDOS.

Pada prinsipnya, Anda dapat membatasi diri pada hal ini, sepenuhnya mengalihdayakan perlindungan Anda. Keputusan ini mempunyai keuntungan, namun ada juga kerugiannya. Faktanya adalah kita dapat berbicara (sekali lagi, tergantung pada apa yang dilakukan perusahaan Anda) tentang kelangsungan bisnis. Dan percayakan hal-hal seperti itu kepada pihak ketiga...

Oleh karena itu, mari kita lihat bagaimana menata lini pertahanan kedua dan ketiga (sebagai tambahan perlindungan dari penyedia).

Jadi, garis pertahanan kedua adalah pemfilteran dan pembatas lalu lintas (polisi) di pintu masuk jaringan Anda.

misalnya 1

Anggaplah Anda telah melindungi diri Anda dari DDOS dengan bantuan salah satu penyedia. Mari kita asumsikan penyedia ini menggunakan Arbour untuk memfilter lalu lintas dan memfilter di tepi jaringannya.

Bandwidth yang dapat “diproses” Arbor terbatas, dan penyedia, tentu saja, tidak dapat terus-menerus meneruskan lalu lintas dari semua mitranya yang memesan layanan ini melalui peralatan penyaringan. Oleh karena itu, dalam kondisi normal, lalu lintas tidak tersaring.

Anggap saja ada serangan banjir SYN. Bahkan jika Anda memesan layanan yang secara otomatis mengalihkan lalu lintas ke pemfilteran jika terjadi serangan, hal ini tidak terjadi secara instan. Selama satu menit atau lebih Anda tetap diserang. Dan ini dapat menyebabkan kegagalan peralatan Anda atau penurunan layanan. Dalam hal ini, membatasi lalu lintas pada perutean tepi, meskipun akan mengarah pada fakta bahwa beberapa sesi TCP tidak akan dibuat selama waktu ini, akan menyelamatkan infrastruktur Anda dari masalah berskala lebih besar.

misalnya 2

Jumlah paket SYN yang sangat besar mungkin bukan hanya disebabkan oleh serangan banjir SYN. Misalkan Anda menyediakan layanan di mana Anda dapat memiliki sekitar 100 ribu koneksi TCP secara bersamaan (ke satu pusat data).

Katakanlah karena masalah jangka pendek dengan salah satu penyedia utama Anda, setengah dari sesi Anda terhenti. Jika aplikasi Anda dirancang sedemikian rupa sehingga, tanpa berpikir dua kali, segera (atau setelah interval waktu tertentu yang sama untuk semua sesi) mencoba membangun kembali koneksi, maka Anda akan menerima setidaknya 50 ribu paket SYN kira-kira serentak.

Jika, misalnya, Anda harus menjalankan jabat tangan ssl/tls di atas sesi ini, yang melibatkan pertukaran sertifikat, maka dari sudut pandang menghabiskan sumber daya untuk penyeimbang beban Anda, ini akan menjadi “DDOS” yang jauh lebih kuat daripada yang sederhana Banjir SYN. Tampaknya penyeimbang harus menangani kejadian seperti itu, tapi... sayangnya, kita dihadapkan pada masalah seperti itu.

Dan, tentu saja, polisi di router edge juga akan menyelamatkan peralatan Anda dalam kasus ini.

Perlindungan tingkat ketiga terhadap DDOS/DOS adalah pengaturan firewall Anda.

Di sini Anda dapat menghentikan serangan tipe kedua dan ketiga. Secara umum, segala sesuatu yang mencapai firewall dapat disaring di sini.

Tip

Cobalah untuk memberi firewall pekerjaan sesedikit mungkin, menyaring sebanyak mungkin pada dua garis pertahanan pertama. Dan itulah kenapa.

Pernahkah terjadi pada Anda bahwa secara kebetulan, saat menghasilkan lalu lintas untuk memeriksa, misalnya, seberapa tahan sistem operasi server Anda terhadap serangan DDOS, Anda “mematikan” firewall Anda, memuatnya hingga 100 persen, dengan lalu lintas pada intensitas normal ? Jika belum, mungkin karena Anda belum mencobanya?

Secara umum, firewall, seperti yang saya katakan, adalah hal yang kompleks, dan berfungsi baik dengan kerentanan yang diketahui dan solusi yang telah diuji, tetapi jika Anda mengirim sesuatu yang tidak biasa, hanya beberapa sampah atau paket dengan header yang salah, maka Anda bersama beberapa, bukan Dengan probabilitas yang sangat kecil (berdasarkan pengalaman saya), Anda bahkan dapat membius peralatan kelas atas. Oleh karena itu, pada tahap 2, dengan menggunakan ACL biasa (pada level L3/L4), hanya izinkan lalu lintas ke jaringan Anda yang seharusnya masuk ke sana.

Memfilter lalu lintas di firewall

Mari lanjutkan pembicaraan tentang firewall. Perlu Anda pahami bahwa serangan DOS/DDOS hanyalah salah satu jenis serangan cyber.

Selain perlindungan DOS/DDOS, kami juga dapat memiliki daftar fitur berikut:

  • firewall aplikasi
  • pencegahan ancaman (antivirus, anti-spyware, dan kerentanan)
  • Pemfilteran URL
  • pemfilteran data (penyaringan konten)
  • pemblokiran file (pemblokiran jenis file)

Terserah Anda untuk memutuskan apa yang Anda butuhkan dari daftar ini.

Untuk dilanjutkan

Sumber: www.habr.com

Tambah komentar