Artikel ini ialah yang keempat dalam siri "Cara Mengambil Kawalan Infrastruktur Rangkaian Anda." Kandungan semua artikel dalam siri dan pautan boleh didapati di sini.

В bahagian pertama Dalam bab ini, kami melihat beberapa aspek keselamatan rangkaian dalam segmen Pusat Data. Bahagian ini akan ditumpukan kepada segmen "Akses Internet".

Akses Internet

Topik keselamatan sudah pasti salah satu topik paling kompleks dalam dunia rangkaian data. Seperti dalam kes sebelumnya, tanpa menuntut kedalaman dan kesempurnaan, saya akan mempertimbangkan di sini agak mudah, tetapi, pada pendapat saya, soalan penting, jawapan yang, saya harap, akan membantu meningkatkan tahap keselamatan rangkaian anda.

Semasa mengaudit segmen ini, beri perhatian kepada aspek berikut:

• reka bentuk
• tetapan BGP
• Perlindungan DOS/DDOS
• penapisan trafik pada tembok api

Design

Sebagai contoh reka bentuk segmen ini untuk rangkaian perusahaan, saya akan mengesyorkan panduan dari Cisco dalam model SELAMAT.

Sudah tentu, mungkin penyelesaian vendor lain akan kelihatan lebih menarik kepada anda (lihat. Kuadran Gartner 2018), tetapi tanpa menggalakkan anda mengikuti reka bentuk ini secara terperinci, saya masih mendapati ia berguna untuk memahami prinsip dan idea di sebaliknya.

Nota:

Dalam SAFE, segmen "Akses Jauh" adalah sebahagian daripada segmen "Akses Internet". Tetapi dalam siri artikel ini kami akan mempertimbangkannya secara berasingan.

Set standard peralatan dalam segmen ini untuk rangkaian perusahaan ialah

• penghala sempadan
• tembok api

Catatan 1

Dalam siri artikel ini, apabila saya bercakap tentang tembok api, maksud saya NGFW.

Catatan 2

Saya tidak mengambil kira pelbagai jenis penyelesaian L2/L1 atau tindanan L2 ke atas L3 yang diperlukan untuk memastikan sambungan L1/L2 dan menghadkan diri saya hanya kepada isu di peringkat L3 dan ke atas. Sebahagiannya, isu L1/L2 telah dibincangkan dalam bab “Pembersihan dan Dokumentasi".

Jika anda tidak menemui tembok api dalam segmen ini, maka anda tidak perlu tergesa-gesa membuat kesimpulan.

Mari kita lakukan perkara yang sama seperti dalam bahagian sebelumnyaMari kita mulakan dengan soalan: adakah perlu menggunakan tembok api dalam segmen ini dalam kes anda?

Saya boleh mengatakan bahawa ini nampaknya merupakan tempat yang paling wajar untuk menggunakan tembok api dan menggunakan algoritma penapisan trafik yang kompleks. DALAM Bahagian 1 Kami menyebut 4 faktor yang mungkin mengganggu penggunaan tembok api dalam segmen pusat data. Tetapi di sini mereka tidak lagi begitu penting.

Contoh 1. Kelewatan

Setakat Internet, tidak ada gunanya bercakap tentang kelewatan walaupun kira-kira 1 milisaat. Oleh itu, kelewatan dalam segmen ini tidak boleh menjadi faktor yang mengehadkan penggunaan tembok api.

Contoh 2. Produktiviti

Dalam sesetengah kes, faktor ini mungkin masih ketara. Oleh itu, anda mungkin perlu membenarkan beberapa trafik (contohnya, trafik daripada pengimbang beban) untuk memintas tembok api.

Contoh 3. Kebolehpercayaan

Faktor ini masih perlu diambil kira, tetapi masih, memandangkan ketidakbolehpercayaan Internet itu sendiri, kepentingannya untuk segmen ini tidak begitu penting seperti untuk pusat data.

Jadi, mari kita anggap bahawa perkhidmatan anda berada di atas http/https (dengan sesi pendek). Dalam kes ini, anda boleh menggunakan dua kotak bebas (tanpa HA) dan jika terdapat masalah penghalaan dengan salah satu daripadanya, pindahkan semua trafik ke yang kedua.

Atau anda boleh menggunakan tembok api dalam mod telus dan, jika gagal, benarkan trafik memintas tembok api semasa menyelesaikan masalah.

Oleh itu, kemungkinan besar hanya harga mungkin faktor yang akan memaksa anda untuk meninggalkan penggunaan tembok api dalam segmen ini.

Penting!

Terdapat godaan untuk menggabungkan firewall ini dengan firewall pusat data (gunakan satu firewall untuk segmen ini). Penyelesaiannya, pada dasarnya, mungkin, tetapi anda perlu memahaminya kerana Firewall Akses Internet sebenarnya berada di barisan hadapan pertahanan anda dan "mengambil alih" sekurang-kurangnya sebahagian daripada trafik berniat jahat, maka, sudah tentu, anda perlu mengambil kira peningkatan risiko bahawa firewall ini akan dilumpuhkan. Iaitu, dengan menggunakan peranti yang sama dalam kedua-dua segmen ini, anda akan mengurangkan ketersediaan segmen pusat data anda dengan ketara.

Seperti biasa, anda perlu memahami bahawa bergantung pada perkhidmatan yang disediakan oleh syarikat, reka bentuk segmen ini mungkin berbeza-beza. Seperti biasa, anda boleh memilih pendekatan yang berbeza bergantung pada keperluan anda.

Contoh

Jika anda penyedia kandungan, dengan rangkaian CDN (lihat, sebagai contoh, siri artikel), maka anda mungkin tidak mahu mencipta infrastruktur merentas berdozen atau bahkan ratusan titik kehadiran menggunakan peranti berasingan untuk penghalaan dan menapis trafik. Ia akan mahal, dan ia mungkin tidak diperlukan.

Untuk BGP anda tidak semestinya perlu mempunyai penghala khusus, anda boleh menggunakan alatan sumber terbuka seperti Quagga. Jadi mungkin yang anda perlukan hanyalah pelayan atau beberapa pelayan, suis dan BGP.

Dalam kes ini, pelayan anda atau beberapa pelayan boleh memainkan peranan bukan sahaja pelayan CDN, tetapi juga penghala. Sudah tentu, masih terdapat banyak butiran (seperti cara memastikan pengimbangan), tetapi ia boleh dilakukan, dan ia merupakan pendekatan yang berjaya kami gunakan untuk salah seorang rakan kongsi kami.

Anda boleh mempunyai beberapa pusat data dengan perlindungan penuh (tembok api, perkhidmatan perlindungan DDOS yang disediakan oleh pembekal Internet anda) dan berdozen atau ratusan titik kehadiran "dipermudahkan" dengan hanya suis dan pelayan L2.

Tetapi bagaimana dengan perlindungan dalam kes ini?

Mari kita lihat, sebagai contoh, yang popular baru-baru ini Serangan DDOS Amplification DNS. Bahayanya terletak pada fakta bahawa sejumlah besar trafik dijana, yang hanya "menyumbat" 100% daripada semua pautan atas anda.

Apa yang kita ada dalam kes reka bentuk kita.

• jika anda menggunakan AnyCast, maka trafik diedarkan antara tempat kehadiran anda. Jika jumlah lebar jalur anda ialah terabit, maka ini dengan sendirinya sebenarnya (namun, baru-baru ini terdapat beberapa serangan dengan trafik berniat jahat mengikut urutan terabit) melindungi anda daripada pautan naik "melimpah".
• Walau bagaimanapun, jika beberapa pautan naik tersumbat, maka anda hanya mengalih keluar tapak ini daripada perkhidmatan (berhenti mengiklankan awalan)
• anda juga boleh meningkatkan bahagian trafik yang dihantar dari pusat data "penuh" anda (dan, dengan itu, dilindungi), dengan itu mengalih keluar sebahagian besar trafik berniat jahat daripada tempat kehadiran yang tidak dilindungi

Dan satu lagi nota kecil untuk contoh ini. Jika anda menghantar trafik yang mencukupi melalui IX, maka ini juga mengurangkan kerentanan anda terhadap serangan sedemikian

Menyediakan BGP

Terdapat dua topik di sini.

• Ketersambungan
• Menyediakan BGP

Kami telah bercakap sedikit tentang ketersambungan dalam Bahagian 1. Intinya adalah untuk memastikan trafik kepada pelanggan anda mengikut laluan yang optimum. Walaupun keoptimuman tidak selalunya hanya mengenai kependaman, kependaman rendah biasanya merupakan penunjuk utama keoptimuman. Bagi sesetengah syarikat ini lebih penting, bagi yang lain ia kurang. Semuanya bergantung pada perkhidmatan yang anda berikan.

1 Contoh

Jika anda seorang pertukaran, dan selang masa kurang daripada milisaat adalah penting kepada pelanggan anda, maka, sudah tentu, tidak boleh bercakap tentang apa-apa jenis Internet sama sekali.

2 Contoh

Jika anda sebuah syarikat permainan dan berpuluh-puluh milisaat adalah penting bagi anda, maka, sudah tentu, ketersambungan adalah sangat penting untuk anda.

3 Contoh

Anda juga perlu memahami bahawa, disebabkan sifat protokol TCP, kadar pemindahan data dalam satu sesi TCP juga bergantung pada RTT (Masa Perjalanan Pergi Balik). Rangkaian CDN juga sedang dibina untuk menyelesaikan masalah ini dengan mengalihkan pelayan pengedaran kandungan lebih dekat dengan pengguna kandungan ini.

Kajian ketersambungan ialah topik yang menarik dengan haknya sendiri, layak untuk artikel atau siri artikelnya sendiri, dan memerlukan pemahaman yang baik tentang cara Internet "berfungsi".

Sumber berguna:

matang.net
bgp.he.net

Contoh

Saya akan berikan satu contoh kecil sahaja.

Katakan bahawa pusat data anda terletak di Moscow, dan anda mempunyai satu pautan naik - Rostelecom (AS12389). Dalam kes ini (rumah tunggal) anda tidak memerlukan BGP, dan kemungkinan besar anda menggunakan kumpulan alamat daripada Rostelecom sebagai alamat awam.

Katakan anda menyediakan perkhidmatan tertentu, dan anda mempunyai bilangan pelanggan yang mencukupi dari Ukraine, dan mereka mengadu tentang kelewatan yang lama. Semasa penyelidikan anda, anda mendapati bahawa alamat IP sesetengah daripada mereka berada dalam grid 37.52.0.0/21.

Dengan menjalankan traceroute, anda melihat bahawa trafik melalui AS1299 (Telia), dan dengan menjalankan ping, anda mendapat purata RTT 70 - 80 milisaat. Anda juga boleh melihat ini di kaca mencari Rostelecom.

Menggunakan utiliti whois (di ripe.net atau utiliti tempatan), anda boleh dengan mudah menentukan bahawa blok 37.52.0.0/21 adalah milik AS6849 (Ukrtelecom).

Seterusnya, dengan pergi ke bgp.he.net anda melihat bahawa AS6849 tidak mempunyai hubungan dengan AS12389 (mereka bukan pelanggan mahupun pautan atas antara satu sama lain, dan mereka juga tidak mempunyai peering). Tapi kalau tengok senarai rakan sebaya untuk AS6849, anda akan melihat, sebagai contoh, AS29226 (Mastertel) dan AS31133 (Megafon).

Sebaik sahaja anda menemui cermin mata penyedia ini, anda boleh membandingkan laluan dan RTT. Sebagai contoh, untuk Mastertel RTT adalah kira-kira 30 milisaat.

Jadi, jika perbezaan antara 80 dan 30 milisaat adalah penting untuk perkhidmatan anda, maka mungkin anda perlu memikirkan tentang ketersambungan, dapatkan nombor AS anda, kumpulan alamat anda daripada RIPE dan sambungkan pautan naik tambahan dan/atau cipta titik kehadiran pada IX.

Apabila anda menggunakan BGP, anda bukan sahaja mempunyai peluang untuk meningkatkan ketersambungan, tetapi anda juga mengekalkan sambungan Internet anda secara berlebihan.

Dokumen ini mengandungi cadangan untuk mengkonfigurasi BGP. Walaupun fakta bahawa pengesyoran ini dibangunkan berdasarkan "amalan terbaik" penyedia, masih (jika tetapan BGP anda tidak begitu asas) ia sudah pasti berguna dan sebenarnya harus menjadi sebahagian daripada pengerasan yang kami bincangkan dalam bahagian pertama.

Perlindungan DOS/DDOS

Kini serangan DOS/DDOS telah menjadi realiti setiap hari bagi banyak syarikat. Malah, anda sering diserang dalam satu bentuk atau yang lain. Hakikat bahawa anda masih belum menyedari perkara ini hanya bermakna bahawa serangan yang disasarkan belum lagi dianjurkan terhadap anda, dan alat perlindungan yang anda gunakan, walaupun mungkin tanpa mengetahuinya (pelbagai perlindungan terbina dalam sistem pengendalian), mencukupi untuk memastikan kemerosotan perkhidmatan yang disediakan diminimumkan untuk anda dan pelanggan anda.

Terdapat sumber Internet yang, berdasarkan log peralatan, melukis peta serangan yang cantik dalam masa nyata.

ia adalah anda boleh mencari pautan kepada mereka.

Kegemaran saya peta daripada CheckPoint.

Perlindungan terhadap DDOS/DOS biasanya berlapis. Untuk memahami sebabnya, anda perlu memahami jenis serangan DOS/DDOS yang wujud (lihat, sebagai contoh, di sini atau di sini)

Iaitu, kita mempunyai tiga jenis serangan:

• serangan volumetrik
• serangan protokol
• serangan aplikasi

Jika anda boleh melindungi diri anda daripada dua jenis serangan terakhir menggunakan, sebagai contoh, tembok api, maka anda tidak boleh melindungi diri anda daripada serangan yang bertujuan untuk "mengelorakan" pautan atas anda (sudah tentu, jika jumlah kapasiti saluran Internet anda tidak dikira dalam terabit, atau lebih baik lagi, dalam puluhan terabit).

Oleh itu, barisan pertahanan pertama ialah perlindungan terhadap serangan "volumetrik", dan pembekal atau pembekal anda mesti memberikan perlindungan ini kepada anda. Jika anda masih belum menyedari perkara ini, maka anda bertuah buat masa ini.

Contoh

Katakan anda mempunyai beberapa pautan naik, tetapi hanya satu daripada pembekal yang boleh memberi anda perlindungan ini. Tetapi jika semua trafik melalui satu pembekal, maka bagaimana pula dengan ketersambungan yang kita bincangkan secara ringkas sebelum ini?

Dalam kes ini, anda perlu mengorbankan sebahagian daripada sambungan semasa serangan. Tetapi

• ini hanya untuk tempoh serangan. Sekiranya berlaku serangan, anda boleh mengkonfigurasi semula BGP secara manual atau automatik supaya trafik hanya melalui pembekal yang memberikan anda "payung". Selepas serangan tamat, anda boleh mengembalikan penghalaan kepada keadaan sebelumnya
• Ia tidak perlu untuk memindahkan semua lalu lintas. Jika, sebagai contoh, anda melihat bahawa tiada serangan melalui beberapa pautan naik atau peering (atau trafik tidak penting), anda boleh terus mengiklankan awalan dengan atribut kompetitif terhadap jiran BGP ini.

Anda juga boleh menyerahkan perlindungan daripada "serangan protokol" dan "serangan aplikasi" kepada rakan kongsi anda.
di sini ialah di sini anda boleh membaca kajian yang baik (terjemahan). Benar, artikel itu berusia dua tahun, tetapi ia akan memberi anda idea tentang pendekatan bagaimana anda boleh melindungi diri anda daripada serangan DDOS.

Pada dasarnya, anda boleh mengehadkan diri anda kepada perkara ini, menyumber keluar sepenuhnya perlindungan anda. Terdapat kelebihan untuk keputusan ini, tetapi terdapat juga kelemahan yang jelas. Hakikatnya ialah kita boleh bercakap (sekali lagi, bergantung pada apa yang syarikat anda lakukan) tentang kelangsungan perniagaan. Dan percayakan perkara sedemikian kepada pihak ketiga...

Oleh itu, mari kita lihat bagaimana untuk mengatur barisan pertahanan kedua dan ketiga (sebagai tambahan kepada perlindungan daripada pembekal).

Jadi, barisan pertahanan kedua ialah penapisan dan pembatas trafik (polis) di pintu masuk ke rangkaian anda.

1 Contoh

Mari kita anggap bahawa anda telah melindungi diri anda dengan payung terhadap DDOS dengan bantuan salah satu penyedia. Katakan pembekal ini menggunakan Arbor untuk menapis trafik dan menapis di pinggir rangkaiannya.

Jalur lebar yang boleh "diproses" oleh Arbor adalah terhad, dan pembekal, sudah tentu, tidak boleh sentiasa melepasi trafik semua rakan kongsinya yang memesan perkhidmatan ini melalui peralatan penapisan. Oleh itu, dalam keadaan biasa, trafik tidak ditapis.

Mari kita andaikan terdapat serangan banjir SYN. Walaupun anda memesan perkhidmatan yang menukar trafik secara automatik kepada penapisan sekiranya berlaku serangan, ini tidak berlaku serta-merta. Selama seminit atau lebih anda masih diserang. Dan ini boleh menyebabkan kegagalan peralatan anda atau kemerosotan perkhidmatan. Dalam kes ini, mengehadkan trafik di penghalaan tepi, walaupun ia akan membawa kepada fakta bahawa beberapa sesi TCP tidak akan ditubuhkan pada masa ini, akan menyelamatkan infrastruktur anda daripada masalah berskala lebih besar.

2 Contoh

Sebilangan besar paket SYN yang luar biasa mungkin bukan sahaja disebabkan oleh serangan banjir SYN. Katakan anda menyediakan perkhidmatan di mana anda boleh mempunyai kira-kira 100 ribu sambungan TCP secara serentak (ke satu pusat data).

Katakan bahawa akibat daripada masalah jangka pendek dengan salah satu penyedia utama anda, separuh daripada sesi anda dihentikan. Jika aplikasi anda direka bentuk sedemikian rupa sehingga, tanpa berfikir dua kali, ia serta-merta (atau selepas beberapa selang masa yang sama untuk semua sesi) cuba untuk mewujudkan semula sambungan, maka anda akan menerima sekurang-kurangnya 50 ribu paket SYN lebih kurang serentak.

Jika, sebagai contoh, anda perlu menjalankan ssl/tls jabat tangan di atas sesi ini, yang melibatkan pertukaran sijil, maka dari sudut kehabisan sumber untuk pengimbang beban anda, ini akan menjadi "DDOS" yang lebih kuat daripada yang mudah. banjir SYN. Nampaknya pengimbang harus mengendalikan acara sebegitu, tetapi... malangnya, kita berhadapan dengan masalah sebegitu.

Dan, sudah tentu, polis di penghala tepi akan menjimatkan peralatan anda dalam kes ini juga.

Tahap ketiga perlindungan terhadap DDOS/DOS ialah tetapan tembok api anda.

Di sini anda boleh menghentikan kedua-dua serangan jenis kedua dan ketiga. Secara umum, semua yang mencapai tembok api boleh ditapis di sini.

Petua

Cuba berikan tembok api sebagai sedikit kerja yang mungkin, tapis sebanyak mungkin pada dua baris pertahanan pertama. Dan itulah sebabnya.

Pernahkah berlaku kepada anda bahawa secara kebetulan, semasa menjana trafik untuk menyemak, sebagai contoh, sejauh mana ketahanan sistem pengendalian pelayan anda terhadap serangan DDOS, anda "membunuh" tembok api anda, memuatkannya kepada 100 peratus, dengan trafik pada intensiti biasa ? Jika tidak, mungkin ia hanya kerana anda belum mencuba?

Secara umum, tembok api, seperti yang saya katakan, adalah perkara yang kompleks, dan ia berfungsi dengan baik dengan kelemahan yang diketahui dan penyelesaian yang diuji, tetapi jika anda menghantar sesuatu yang luar biasa, hanya beberapa sampah atau paket dengan pengepala yang salah, maka anda bersama beberapa, bukan Dengan kebarangkalian yang kecil (berdasarkan pengalaman saya), anda boleh membingungkan walaupun peralatan atasan. Oleh itu, pada peringkat 2, menggunakan ACL biasa (pada tahap L3/L4), hanya benarkan trafik ke dalam rangkaian anda yang sepatutnya masuk ke sana.

Menapis trafik pada tembok api

Mari kita teruskan perbualan tentang tembok api. Anda perlu memahami bahawa serangan DOS/DDOS hanyalah satu jenis serangan siber.

Selain perlindungan DOS/DDOS, kami juga boleh mempunyai sesuatu seperti senarai ciri berikut:

• firewall aplikasi
• pencegahan ancaman (antivirus, anti-perisian pengintip dan kerentanan)
• Penapisan URL
• penapisan data (penapisan kandungan)
• menyekat fail (menyekat jenis fail)

Terpulang kepada anda untuk memutuskan perkara yang anda perlukan daripada senarai ini.

Perlu diteruskan

Sumber: www.habr.com