Tidak ada gerbang keamanan jaringan UTM yang dapat menghargai diri sendiri yang dapat dilakukan tanpa Intrusion Detection System (IDS). Hal lain adalah bahwa opsi tersebut sering ditunjukkan oleh pabrikan untuk kutu agar dapat bersaing dengan pesaing. Saya tahu dari pengalaman saya sebagai penguji bagaimana hal ini terjadi - sepertinya ada IDS, tetapi sebenarnya itu tidak baik. Itulah sebabnya, ketika saya ditawari untuk menguji perangkat keras UTM yang relatif murah, saya menyarankan pertama-tama untuk "mengusir" OWL-nya.
UTM-piece Traffic Inspector Next Generation S100 dan Cisco 2960G SwitchJika Anda memiliki pengalaman bekerja dengan IDS, menarik untuk membacanya di komentar ke artikel. Disarankan - bukan tentang perangkat keras yang mahal (jelas bahwa beberapa Cisco NGFW bagus untuk satu juta), tetapi tentang solusi yang lebih terjangkau. Saya pikir administrator lokalka dan pengguna potensial gateway jaringan akan penasaran untuk membahas siapa yang bekerja dengan IDS dan apakah perlu membeli dengan harga tinggi, ketika Anda dapat, setelah menari dengan rebana, mencapai hal yang sama dengan lebih sedikit uang.
Dalam tes ini, kita berbicara tentang model S100 - harga paling terjangkau di lini Lalu Lintas Inspektur Generasi Selanjutnya (angka berarti bahwa itu dirancang untuk 100 pelanggan). Berikut ini
deskripsinya di situs web resmi >>> . Singkatnya, perangkat keras berisi, misalnya, filter jaringan, VPN, pemblokir sumber daya, dan, tentu saja, IDS.
Saya mengusulkan metodologi pengujian sederhana - kami memeriksa throughput, dan kami membangun ketergantungan dari jumlah paket yang dijatuhkan pada intensitas lalu lintas dengan peningkatan 50, 100, 150 dan 200 Mb / s. Mengapa kita mengambil jeda seperti itu? Kami mulai dari 100 Mb / s - permintaan klien paling populer, dan menunda plus dan minus darinya untuk melihat apa yang terjadi dalam mode yang dimuat lebih atau kurang, serta dalam mode ekstrim 200 Mb / s.
Pengalaman hidup memberi tahu saya bahwa dengan semua aturan aktif, S100 mungkin tidak menarik, jadi saya menyarankan prosedur yang dijelaskan untuk dilakukan dalam tiga mode: pertama ketika semua aturan aktif, kemudian dengan bagian aturan dimatikan (sebut saja Grup No. 1) dan, akhirnya, hanya ketika itu aktif hanya beberapa aturan (sebut saja Grup No. 2). Kami membentuk grup aturan berikut:
- Grup No. 0: yah, itu bisa dimengerti, semua aturan tanpa kecuali.
- Grup No. 1: Grup aturan Thread yang Muncul (Saya sudah tahu aturan sejak menguji IDS Snort, dengan pengecualian aturan game yang sedang muncul).
- Grup No. 2: sekelompok aturan yang saya anggap hanya mengikat IDS (lihat di bawah), termasuk penambahan aturan p2p, karena dari pengalaman saya sendiri, saya tahu bagaimana perusahaan besar secara negatif berhubungan dengan fakta bahwa karyawan mereka secara aktif menggunakan perusahaan jaringan untuk mengunduh acara TV favorit Anda.
Pengujian
dimungkinkan menggunakan
utilitas tcpreplay . Utilitas ini memungkinkan Anda untuk memutar lalu lintas jaringan yang telah direkam sebelumnya pada kecepatan tertentu. Perintah:
tcpreplay –i <interface> -l 0 testTI.pcap . File
testTI.pcap berisi 1 146 313 paket (kami memilih volume sedemikian sehingga, di satu sisi, ada statistik yang baik, di sisi lain, waktu untuk "berjalan" tidak akan terlalu lama, dalam kasus kami, tidak lebih dari 15 menit). Selain itu, seperti yang saya katakan, kami meluncurkan pelacak torrent.
Tata letak bangku tes:
Jika seseorang memiliki pertanyaan tentang metodologi pengujian, saya siap menjawab dalam komentar.
Jadi hasilnya.
Grup 0Pengujian pada set lengkap melibatkan pemuatan semua aturan, dan ada 30 305 di antaranya.
Saat menguji, kami menggunakan pengaturan IDS default:
Kami memulai pengujian dengan 100 Mb / s dan kami memahami bahwa sepotong besi hampir tidak dapat menarik: dari 114 ribu paket, 109 ribu dibuang! Jadi tidak ada gunanya menguji pada 150 dan bahkan lebih pada 200 Mb / s. Sebaliknya, saya mengusulkan untuk memberikan perangkat kesempatan dan melakukan tes tambahan pada 10 Mb / s. Hasilnya dalam tabel:
Catatan:
kernel_packets - paket yang dikirim;
kernel_drops - paket yang dijatuhkan. Seperti yang Anda lihat, dengan pengaturan default dan dengan seperangkat aturan lengkap, terjadi kerugian paket besar (> 30% relatif terhadap kernel_packets). Mari berharap bahwa mengoptimalkan aturan untuk pengaturan akan mengubah situasi;
decoder_packets - jumlah paket yang diproses dengan benar oleh sistem;
detect_alerts - jumlah serangan yang terdeteksi. Sebagian besar serangan adalah dari tipe Paket Terpecah, tetapi serangan Deteksi Pelacak Torrent juga telah diidentifikasi.
Nomor grup 1Jelas, perangkat keras tidak dioptimalkan untuk berfungsi sebagai IDS kuat penuh, tetapi ada ruang untuk manuver, yaitu, kemampuan untuk mengubah mekanisme pencarian untuk rute, menonaktifkan unduhan konten paket (payload), dan menonaktifkan kelompok aturan dan kelompok paket tertentu. Sebuah eksperimen kecil dengan pengaturan - dan kami sampai pada opsi yang saya sajikan pada gambar berikut.
Daftar aturan aktif yang kami tinggalkan:
Hasil tes:
Seperti yang Anda lihat, gambar meningkat secara signifikan dengan kelompok aturan ini (persentase paket yang dijatuhkan menurun beberapa kali). Serangan seperti "Mendeteksi pelacak torrent" berhasil dideteksi (serangan "Paket terfragmentasi" tidak lagi muncul).
Nomor grup 2Pengaturannya sama. Daftar aturan aktif:
Hasilnya dalam tabel:
Di sini gambar pemrosesan paket lebih baik, yang diharapkan.RingkasanTabel hasil akhir, dinyatakan sebagai persentase dari kernel_drops relatif terhadap kernel_packets, ditunjukkan di bawah ini:
Secara grafis, hasilnya adalah sebagai berikut:
Seperti yang Anda lihat, jumlah aturan dan pengaturan aktif secara langsung mempengaruhi efisiensi. Tidak masuk akal untuk mengaktifkan pengaturan ke maksimum dan semua aturan pada saat yang sama - kerugian segera turun skala bahkan dengan 10 Mb / s. Dalam mode yang dioptimalkan, perangkat keras terasa normal hingga 100 Mb / s, tetapi kerugian meningkat tajam pada lalu lintas yang lebih intensif. Namun, untuk penggunaan "kantor", 100 Mb / s sudah cukup. Jika Anda menggerakkan perangkat dengan kecepatan ini dan memilih aturan, Anda dapat memperoleh IDS yang cukup memuaskan.
Mungkin, untuk menggunakan set lengkap aturan, diperlukan perbaikan untuk menggunakan mekanisme pf_ring (https://www.ntop.org/products/packet-capture/pf_ring/) sebagai mekanisme untuk mentransfer paket ke ruang pengguna dari buffer antarmuka jaringan. Untuk melakukan ini, Anda perlu menggunakan beberapa contoh Suricata, yang, tentu saja, akan mengambil sumber daya dari proses lain, tetapi mungkin gim ini akan bernilai lilin.
Saya ulangi bahwa, menurut pendapat saya, tujuan utama dari perangkat yang diuji adalah firewall, dan opsi IDS adalah tambahan. Jujur, saya sudah siap dengan kenyataan bahwa perangkat keras akan gagal. Ternyata dengan persepsi gutta tertentu dari administrator sistem, sistem deteksi intrusi di S100 sepenuhnya operasional.
PS Seperti yang saya katakan di atas, saya mendorong pembaca untuk menulis tentang pengalaman mereka dalam menggunakan IDS dalam solusi yang relatif murah.
Tes PPS diposting di akun pabrikan, karena saya tidak ingin "bersinar" sendiri. Meskipun demikian, saya siap untuk menjawab semua pertanyaan dan debat dalam komentar, tetapi, sekali lagi, bukan atas nama saya sendiri :)