Artikel kedua ini menjelaskan cara mengatasi masalah dengan filter paket. Alih-alih menyajikan tabel yang sudah jadi dalam bentuk “masalah” – “solusi”, diberikan metode pendekatan sistematis untuk memecahkan masalah yang muncul.

Artikel kedua ini (dalam rangkaian tiga artikel) menjelaskan cara mengatasi masalah filter paket. Alih-alih menyajikan tabel yang sudah jadi dalam bentuk “masalah” – “solusi”, diberikan metode pendekatan sistematis untuk memecahkan masalah yang muncul.

Perkenalan

Filter paket menerapkan kebijakan pemfilteran dengan melewati serangkaian aturan dan, karenanya, memblokir atau meneruskan paket. Bab ini menjelaskan cara memverifikasi bahwa kebijakan pemfilteran diterapkan dengan benar, dan cara menemukan kesalahan jika tidak.

Secara umum, dalam bab ini kita akan membandingkan tugas menulis seperangkat aturan pemfilteran dengan pemrograman. Jika Anda tidak memiliki keterampilan pemrograman, maka perbandingan ini akan terasa agak rumit bagi Anda. Namun menulis peraturan itu sendiri tidak memerlukan gelar di bidang ilmu komputer atau pengalaman pemrograman, bukan?

Jawabannya adalah tidak, Anda mungkin tidak memerlukannya. Bahasa yang digunakan untuk mengkonfigurasi filter paket dibuat mirip dengan bahasa manusia. Misalnya:

memblokir semua

pingsan semua simpan negara

meneruskan proto tcp ke port apa pun yang disimpan status www

Faktanya, Anda tidak perlu memiliki seorang pemrogram di dekat Anda untuk memahami apa yang dilakukan kumpulan ini atau bahkan, menggunakan intuisi, untuk menulis kebijakan pemfilteran serupa. Bahkan ada kemungkinan besar bahwa seperangkat aturan pemfilteran yang dibuat serupa ini akan melakukan tindakan yang dimaksudkan oleh pembuatnya.

Sayangnya, komputer hanya melakukan apa yang Anda minta, bukan apa yang Anda ingin mereka lakukan. Parahnya, mereka tidak akan bisa membedakan apa yang mereka inginkan dengan apa yang sebenarnya mereka inginkan, jika memang ada perbedaan seperti itu. Ini berarti bahwa jika komputer tidak melakukan apa yang Anda inginkan dengan benar, meskipun Anda merasa telah menjelaskan instruksinya dengan jelas, Andalah yang harus menemukan perbedaannya dan mengubah instruksinya. Dan karena ini adalah masalah umum dalam pemrograman, kita dapat melihat bagaimana programmer menanganinya. Di sinilah ternyata keterampilan dan metode yang digunakan untuk menguji dan men-debug program serta aturan pemfilteran sangat mirip. Namun di sini Anda tidak memerlukan pengetahuan tentang bahasa pemrograman apa pun untuk memahami implikasi pengujian dan debugging.

Kebijakan penyaringan yang baik.

Kebijakan pemfilteran adalah spesifikasi informal tentang apa yang kita inginkan dari firewall. Sebaliknya, seperangkat aturan, implementasi suatu spesifikasi, adalah seperangkat instruksi standar, sebuah program yang dijalankan oleh mesin. Oleh karena itu, untuk menulis sebuah program, Anda harus menentukan apa yang harus dilakukannya.

Jadi langkah pertama dalam konfigurasi firewall adalah menentukan secara informal apa yang ingin Anda capai. Koneksi mana yang harus diblokir atau diizinkan masuk?

Contohnya adalah:

Ada tiga jaringan yang harus dipisahkan satu sama lain oleh firewall. Koneksi apa pun dari satu jaringan ke jaringan lainnya melewati firewall. Firewall memiliki 3 antarmuka, yang masing-masing terhubung ke jaringan yang sesuai:

$ext_if - ke jaringan eksternal.

$dmz_if - DMZ dengan server.

$lan_if - LAN dengan stasiun kerja.

Host di LAN harus bebas terhubung ke host mana pun di DMZ atau jaringan eksternal.

Server di DMZ harus dapat berkomunikasi secara bebas dengan host di jaringan eksternal. Host jaringan eksternal hanya dapat terhubung ke server berikut di DMZ:

Server web 10.1.1.1 port 80

Server email 10.2.2.2 port 25

Semua koneksi lainnya harus dilarang (misalnya, dari mesin di jaringan eksternal ke mesin di LAN).

Kebijakan ini diungkapkan secara informal agar siapapun yang membacanya dapat memahaminya. Harus sangat spesifik sehingga pembaca dapat dengan mudah merumuskan jawaban atas pertanyaan seperti 'Haruskah koneksi dari host X ke host Y diperbolehkan masuk (atau keluar) pada antarmuka Z?'. Jika Anda bertanya-tanya apakah kebijakan Anda tidak memenuhi persyaratan ini, itu karena kebijakan tersebut tidak didefinisikan dengan baik.

Kebijakan yang “tidak jelas” seperti “hanya mengizinkan segala sesuatu yang penting” atau “memblokir serangan” perlu diklarifikasi, atau Anda tidak akan dapat menerapkan atau memverifikasi kebijakan tersebut. Seperti dalam pengembangan perangkat lunak, tugas-tugas yang diformalkan dengan buruk jarang menghasilkan implementasi yang tepat atau benar. (“Mengapa Anda tidak mulai menulis kode, sementara saya mencari tahu apa yang dibutuhkan pelanggan”).

Seperangkat aturan yang mengimplementasikan suatu kebijakan

Kumpulan aturan ditulis sebagai file teks yang berisi kalimat dalam bahasa formal. Sama seperti kode sumber diproses dan diterjemahkan ke dalam instruksi kode mesin oleh kompiler, "teks sumber" dari kumpulan aturan diproses oleh pfctl dan hasilnya diinterpretasikan oleh pf di kernel.

Ketika kode sumber melanggar aturan bahasa formal, parser melaporkan kesalahan sintaksis dan menolak memproses file lebih lanjut. Kesalahan ini merupakan kesalahan waktu kompilasi dan biasanya dapat diperbaiki dengan cepat. Ketika pfctl tidak dapat mengurai file aturan Anda, pfctl akan mencetak baris yang berisi kesalahan dan pesan yang kurang lebih informatif tentang apa yang tidak dapat diurai. Sampai seluruh file diproses tanpa satu kesalahan pun, pfctl tidak akan mengubah kumpulan aturan sebelumnya di kernel. Dan karena file tersebut mengandung satu atau lebih kesalahan sintaksis, tidak akan ada "program" yang dapat dijalankan oleh pf.

Jenis kesalahan kedua disebut “kesalahan run-time” karena terjadi ketika program yang ditulis dengan benar secara sintaksis berhasil diterjemahkan dan dijalankan. Secara umum, dalam bahasa pemrograman, hal ini dapat terjadi ketika suatu program dibagi dengan nol, mencoba mengakses area memori yang tidak valid, atau kehabisan memori. Namun karena kumpulan aturan hanya secara samar-samar menyerupai fungsionalitas bahasa pemrograman, sebagian besar kesalahan ini tidak dapat terjadi selama penerapan aturan, misalnya, aturan tidak dapat menyebabkan apa yang disebut. “sistem crash”, seperti yang terjadi pada program normal. Namun, seperangkat aturan dapat menyebabkan kesalahan serupa, dalam bentuk pemblokiran atau, sebaliknya, mengizinkan paket yang tidak mematuhi kebijakan. Hal ini terkadang disebut kesalahan logis, kesalahan yang tidak menimbulkan pengecualian atau berhenti, namun hanya memberikan hasil yang salah.

Jadi, sebelum kita dapat mulai memeriksa apakah firewall mengimplementasikan kebijakan keamanan dengan benar, kita harus berhasil memuat kumpulan aturan terlebih dahulu.

Kesalahan penganalisis

Kesalahan penganalisis terjadi ketika mencoba memuat daftar aturan menggunakan pfctl, misalnya:

# pfctl -F/dll/hal.konf

/ dll/hal.konf:3:sintaksiskesalahan

Pesan ini menunjukkan bahwa ada kesalahan sintaksis pada baris 3 dari /etc/pf.conf dan pfctl tidak dapat memuat aturan. Set di kernel tidak berubah, tetap sama seperti sebelum mencoba memuat yang baru.

Ada banyak jenis kesalahan yang dihasilkan oleh pfctl. Untuk memulai pfctl, Anda hanya perlu membacanya dengan cermat. Mungkin tidak semua bagian pesan akan langsung mengungkapkan maknanya kepada Anda, namun Anda perlu membaca semuanya, karena... Ini akan memudahkan untuk memahami apa yang salah nantinya. Jika sebuah pesan berisi bagian dari formulir “nama file: nomor: teks”, pesan tersebut mengacu pada baris dengan nomor yang sesuai dalam file yang ditentukan.

Langkah selanjutnya adalah melihat jalur keluaran menggunakan editor teks (di vi Anda dapat menuju ke jalur 3 dengan mengetik 3G dalam mode bip), atau seperti ini:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 blok semuanya

3 pingsan pada $int_if inet semua status kep

membagikan inet pada $int_if semua status kep

Masalahnya bisa jadi hanya kesalahan ketik, seperti dalam kasus ini (“kep” dan bukan “keep”). Setelah diperbaiki, coba muat ulang file:

# pfctl -F/dll/hal.konf

/ dll/hal.konf:3:sintaksiskesalahan

# kepala -n 3 /etc/pf.conf | ekor -n 1

membagikan inet pada $int_if semua status tetap

Sekarang semua kata kunci sudah benar, tetapi setelah diperiksa lebih dekat kita melihat bahwa penempatan kata kunci “inet” sebelum “di $int_if” salah. Hal ini menggambarkan bahwa baris yang sama dapat mengandung lebih dari satu kesalahan. Pfctl mencetak kesalahan pertama yang ditemukannya dan berhenti dijalankan. Jika nomor baris yang sama dikeluarkan saat restart, berarti masih ada kesalahan di dalamnya, atau kesalahan sebelumnya tidak diperbaiki dengan benar.

Kata kunci yang ditempatkan secara tidak tepat juga merupakan kesalahan umum. Hal ini dapat diketahui dengan membandingkan aturan tersebut dengan sintaks referensi BNF di akhir file bantuan man pf.conf(5), yang berisi:

aturan-pf= tindakan [ ("masuk" | "keluar") ]

["catatan" | "log-semua" ] [ "cepat" ]

[ "aktif" ifspec ] [ rute ] [ af ] [ protospec ]

host [daftar filteropt]

ifspec = ([ "!" ] nama antarmuka) | "(" daftar antarmuka ")"

af = "masuk" | "inet6"

Apa maksudnya kata kunci “inet” harus mengikuti “on $int_if”

Mari kita perbaiki dan coba lagi:

# pfctl -F/dll/hal.konf

/ dll/hal.konf:3:sintaksiskesalahan

# kepala -n 3 /etc/pf.conf | ekor -n 1

pingsan pada $int_if inet semua status simpan

Tidak ada kesalahan nyata yang tersisa sekarang. Namun kami tidak melihat semua detail yang menyertainya! Garisnya bergantung pada definisi makro $inf_if. Apa yang bisa didefinisikan secara salah?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

blok jatuhkan semua

/etc/pf.conf:3: kesalahan sintaksis

Setelah memperbaiki kesalahan ketik “fxp 0” menjadi “fxp0”, coba lagi:

# pfctl -F/dll/hal.konf

Tidak adanya pesan menandakan bahwa file berhasil diunduh.

Dalam beberapa kasus, pfctl mungkin menghasilkan pesan kesalahan yang lebih spesifik dari sekadar "kesalahan sintaksis":

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port hanya berlaku untuk tcp/udp

/etc/pf.conf:3: melewatkan aturan karena kesalahan

/etc/pf.conf:3: aturan diperluas hingga tidak ada kombinasi yang valid

# kepala -n 3 /etc/pf.conf | ekor -n 1

membagikan $int_if ke port ssh keep state

Baris pertama pesan kesalahan adalah yang paling informatif dibandingkan baris lainnya. Dalam hal ini, masalahnya adalah aturannya, saat menentukan port, tidak menentukan protokol - tcp atau udp.

Dalam kasus yang jarang terjadi, pfctl akan menjadi bingung dengan adanya karakter yang tidak dapat dicetak atau spasi yang tidak diperlukan dalam file, kesalahan seperti itu tidak mudah dideteksi tanpa pemrosesan khusus pada file:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: spasi setelah \

/etc/pf.conf:2: kesalahan sintaksis

# cat -ent /etc/pf.conf

1 blok semua$

2 membagikan permata0 dari mana saja ke mana saja \ $

3 ^ Saya simpannegara bagian$

Masalahnya di sini adalah karakter spasi, setelah garis miring terbalik tetapi sebelum akhir baris kedua, ditunjukkan dengan tanda “$” pada keluaran cat -e.

Setelah ruleset berhasil dimuat, alangkah baiknya lihat hasilnya:

$ kucing /etc/pf.conf

memblokir semua

# berpindah dari mana saja ke mana saja \

meneruskan dari 10.1.2.3 ke mana saja

$ pfctl -f /etc/pf.conf

$ pfctl -sr

memblokirmenjatuhkansemua

Tanda "garis miring terbalik" di akhir baris komentar sebenarnya berarti baris komentar akan berlanjut di bawah.

Memperluas daftar yang diapit tanda kurung kurawal () dapat menghasilkan hasil yang mungkin mengejutkan Anda, dan pada saat yang sama menunjukkan kumpulan aturan yang diproses oleh penganalisis:

$ kucing /etc/pf.conf

meneruskan dari ( !10.1.2.3, !10.2.3.4 ) ke mana saja

$ pfctl -nvf /etc/pf.conf

lewati internet dari ! 10.1.2.3 kepada siapa saja

lewati internet dari ! 10.2.3.4kesetiap

Tangkapannya di sini adalah bahwa ekspresi "( !10.1.2.3, !10.2.3.4 )" tidak akan berarti "semua alamat kecuali 10.1.2.3 dan 10.2.3.4", ekspresi yang diperluas itu sendiri berarti mencocokkan alamat mana pun yang mungkin.

Anda harus memuat ulang aturan Anda setelah melakukan perubahan permanen untuk memastikan bahwa pfctl dapat memuatnya saat mesin di-boot ulang. Pada OpenBSD, skrip startup rc di /etc/rc pertama-tama memuat sekumpulan kecil aturan default yang memblokir semua lalu lintas kecuali yang diperlukan selama fase boot (seperti dhcp atau ntp). Jika skrip tidak dapat memuat kumpulan aturan sebenarnya dari /etc/pf.conf karena kesalahan sintaksis yang terjadi sebelum mesin di-boot ulang tanpa memeriksa, maka kumpulan aturan default akan tetap aktif. Untungnya, set ini memungkinkan koneksi ssh masuk, sehingga masalahnya dapat diselesaikan dari jarak jauh.

Pengujian

Karena kita memiliki kebijakan yang didefinisikan dengan sangat tepat dan seperangkat aturan yang harus diterapkan, maka istilah pengujian dalam kasus kita berarti kepatuhan rangkaian hasil dengan kebijakan yang diberikan.

Hanya ada dua cara agar aturan tidak berfungsi dengan benar: memblokir koneksi yang seharusnya diizinkan, dan sebaliknya, mengizinkan koneksi yang seharusnya diblokir.

Pengujian secara umum menyiratkan pendekatan sistematis terhadap penciptaan berbagai jenis koneksi secara teratur. Tidak mungkin untuk memeriksa semua kemungkinan kombinasi sumber/tujuan dan port terkait pada antarmuka, karena firewall secara teoritis dapat menghadapi sejumlah besar kombinasi seperti itu. Memastikan bahwa seperangkat aturan pada awalnya benar hanya dapat dicapai untuk kasus-kasus yang sangat sederhana. Dalam praktiknya, solusi terbaik adalah membuat daftar koneksi pengujian berdasarkan kebijakan keamanan, sehingga setiap item kebijakan terpengaruh. Jadi, untuk contoh kebijakan kita, daftar pengujiannya adalah sebagai berikut:

Koneksi dari LAN ke DMZ (harus dilewati)

dari LAN ke jaringan eksternal (harus dilewati)

dari DMZ ke LAN (harus diblokir)

dari DMZ ke jaringan eksternal (harus dilewati)

dari jaringan eksternal ke DMZ ke 10.1.1.1 pada port 80 (harus dilewati)

dari jaringan eksternal ke DMZ ke 10.1.1.1 pada port 25 (harus diblokir)

dari jaringan eksternal ke DMZ ke 10.2.2.2 pada port 80 (harus diblokir)

dari jaringan eksternal ke DMZ ke 10.2.2.2 pada port 25 (harus dilewati)

dari jaringan eksternal ke LAN (harus diblokir)

Hasil yang diharapkan harus ditentukan dalam daftar ini sebelum pengujian dimulai.

Ini mungkin terdengar aneh, tetapi tujuan dari setiap pengujian adalah untuk menemukan kesalahan dalam penerapan seperangkat aturan firewall, dan bukan sekadar menyatakan ketidakhadirannya. Dan tujuan akhir dari proses ini adalah untuk membangun seperangkat aturan tanpa kesalahan, jadi jika menurut Anda kemungkinan besar ada kesalahan, lebih baik Anda menemukannya daripada melewatkannya. Dan jika Anda berperan sebagai penguji, Anda harus mengikuti gaya berpikir destruktif dan mencoba melewati batasan firewall. Dan hanya fakta bahwa pembatasan tidak dapat dilanggar akan menjadi konfirmasi yang masuk akal bahwa seperangkat aturan tidak mengandung kesalahan.

Koneksi TCP dan UDP dapat diperiksa menggunakan nc. nc dapat digunakan sebagai klien dan server (menggunakan opsi -l). Dan untuk permintaan dan tanggapan ICMP, klien terbaik untuk diperiksa adalah ping.

Untuk memeriksa apakah koneksi diblokir, Anda dapat menggunakan cara apa pun yang mencoba membuat koneksi ke server.

Dengan menggunakan alat pengumpulan port seperti nmap, Anda dapat dengan mudah memindai banyak port, bahkan di banyak host. Jika hasilnya tidak terlihat jelas, lihat halaman manual. Misalnya, untuk port TCP, pemindai mengembalikan nilai 'tanpa filter' ketika nmap menerima RST dari pf. Selain itu, pf yang dipasang pada mesin yang sama dengan pemindai dapat memengaruhi pengoperasian nmap yang benar.

Alat pemindaian yang lebih canggih mungkin mencakup alat untuk membuat paket IP yang terfragmentasi atau salah.

Untuk memverifikasi bahwa filter meneruskan koneksi yang ditentukan dalam kebijakan, metode terbaik adalah memeriksa menggunakan aplikasi yang selanjutnya akan digunakan oleh klien. Jadi, memeriksa jalannya koneksi http dari mesin klien server web yang berbeda, serta dari browser yang berbeda, dan mengambil sampel konten yang berbeda akan lebih baik daripada sekadar mengonfirmasi pembuatan sesi TCP ke nc, yang berfungsi sebagai bagian server. Berbagai faktor, seperti sistem operasi host, juga dapat menyebabkan kesalahan – masalah dengan penskalaan jendela TCP atau respons TCP SACK antara sistem operasi tertentu.

Ketika titik tes berikutnya dilewati, hasilnya mungkin tidak selalu sama. Sambungan mungkin terputus selama proses pembuatan sambungan jika firewall mengembalikan RST. Pembuatan koneksi mungkin gagal karena waktu habis. Sambungan mungkin telah terjalin sepenuhnya dan berfungsi, namun setelah beberapa saat mungkin terhenti atau terputus. Koneksi mungkin bertahan, namun throughput atau latensi mungkin berbeda dari yang diharapkan, lebih tinggi atau lebih rendah (jika Anda menggunakan AltQ untuk membatasi bandwidth).

Seperti hasil yang diharapkan, selain melewatkan/memblokir koneksi, Anda juga dapat mencatat apakah paket dicatat, bagaimana paket tersebut diterjemahkan, dirutekan, dan apakah penghitung yang diperlukan ditingkatkan, jika perlu. Jika aspek-aspek ini penting bagi Anda, maka aspek-aspek tersebut juga perlu disertakan dalam metodologi pengujian.

Kebijakan Anda mungkin mencakup persyaratan terkait kinerja, respons terhadap kelebihan beban, dan toleransi kesalahan. Dan mereka mungkin memerlukan tes terpisah. Jika Anda menyiapkan sistem yang toleran terhadap kesalahan menggunakan CARP, Anda mungkin ingin mengetahui apa yang terjadi pada berbagai jenis kegagalan.

Ketika Anda mengamati hasil yang berbeda dari yang Anda harapkan, catat langkah demi langkah langkah-langkah Anda selama tes, apa yang Anda harapkan, mengapa Anda mengharapkannya, hasil yang Anda dapatkan, dan bagaimana hasil tersebut berbeda dari harapan Anda. Ulangi tes untuk melihat apakah situasinya sama atau berbeda dari waktu ke waktu. Coba ubah parameter masukan pengujian (alamat atau port sumber/tujuan).

Sejak Anda memiliki masalah yang dapat direproduksi, Anda perlu mulai melakukan debug untuk mencari tahu mengapa segala sesuatunya tidak berjalan seperti yang Anda harapkan dan bagaimana cara "memperbaikinya". Dengan pengaturan ini, Anda harus mengubah kumpulan aturan dan mengulangi semua pengujian, termasuk pengujian yang tidak menimbulkan kesalahan, karena dengan mengubah aturan, Anda dapat secara tidak sengaja memengaruhi pengoperasian bagian kumpulan aturan yang berfungsi dengan benar.

Prinsip yang sama berlaku untuk perubahan lain yang dilakukan pada himpunan. Proses peninjauan formal ini akan membantu membuat proses tersebut tidak terlalu rentan menimbulkan kesalahan. Mungkin tidak perlu mengulangi seluruh prosedur untuk perubahan kecil, namun jumlah dari beberapa perubahan kecil dapat mempengaruhi hasil keseluruhan pemrosesan set. Anda dapat menggunakan sistem kontrol versi seperti cvs untuk bekerja dengan file konfigurasi Anda karena... ini akan membantu dalam menyelidiki perubahan yang menyebabkan kesalahan. Jika Anda tahu bahwa bug tidak terjadi seminggu yang lalu, namun sekarang terjadi, melihat semua perubahan yang Anda buat selama seminggu terakhir akan membantu Anda menyadari masalahnya, atau setidaknya mengembalikan ke titik di mana bug tersebut tidak terjadi. tidak ada.

Kumpulan aturan yang tidak sepele dapat dianggap sebagai program; aturan tersebut jarang sekali sempurna pada versi pertamanya, dan perlu waktu untuk yakin bahwa aturan tersebut bebas dari kesalahan. Namun, tidak seperti program biasa, yang tidak pernah dianggap bebas kesalahan oleh sebagian besar pemrogram, rangkaian aturan masih cukup sederhana untuk mendekati definisi ini.

Men-debug

Istilah debugging biasanya mengacu pada menemukan dan menghilangkan kesalahan pemrograman dalam program komputer. Atau, dalam konteks kumpulan aturan firewall, istilah ini merujuk pada proses menemukan alasan mengapa kumpulan aturan tersebut tidak memberikan hasil yang diinginkan. Ada beberapa jenis kesalahan yang dapat muncul dalam aturan, namun metode untuk menemukannya mirip dengan pemrograman.

Sebelum Anda mulai mencari penyebab masalahnya, Anda harus memahami dengan jelas sifat masalahnya. Jika Anda sendiri melihat kesalahan tersebut selama pengujian, itu sangat sederhana. Namun jika orang lain melaporkan bug kepada Anda, membuat tujuan yang jelas dari laporan bug yang tidak tepat dapat menjadi tantangan. Tempat terbaik untuk memulai adalah dengan mereproduksi sendiri kesalahan tersebut.

Masalah jaringan mungkin tidak selalu disebabkan oleh filter paket. Sebelum Anda memfokuskan perhatian Anda untuk men-debug konfigurasi pf, Anda perlu memastikan bahwa masalahnya disebabkan oleh filter paket. Ini mudah dilakukan dan juga akan menghemat waktu mencari masalah di tempat lain. Cukup matikan pf dengan pfctl -d dan periksa apakah masalah terjadi lagi. Jika demikian, aktifkan pf dengan pfctl -e dan lihat apa yang terjadi. Cara ini tidak akan berhasil dalam beberapa kasus, misalnya jika pf tidak melakukan terjemahan alamat jaringan (NAT) dengan benar, maka mematikan pf jelas tidak akan menghilangkan kesalahan tersebut. Namun jika hal ini memungkinkan, cobalah untuk memastikan bahwa filter paketlah yang bermasalah.

Oleh karena itu, jika masalahnya ada pada filter paket, hal pertama yang perlu Anda lakukan adalah memastikan bahwa pf benar-benar berfungsi dan seperangkat aturan yang diperlukan berhasil dimuat:

# pfctl -si | status grep

Status: Diaktifkan selama 4 hari 13:47:32Debug: Mendesak

# pfctl -sr

lulus cepat lo0 semua

lulus cepat pada enc0 semua

Debugging berdasarkan protokol

Langkah debugging selanjutnya adalah mengidentifikasi masalah pada koneksi jaringan tertentu. Jika Anda mendapat pesan: “Pesan instan di aplikasi X tidak berfungsi,” Anda perlu mencari tahu koneksi jaringan apa yang digunakan. Kesimpulannya mungkin seperti “host A tidak dapat membuat koneksi ke host B di port C.” Terkadang tugas ini adalah yang paling sulit, tetapi jika Anda memiliki informasi tentang koneksi yang diperlukan dan Anda tahu bahwa firewall tidak mengizinkannya, Anda hanya perlu mengubah aturan untuk mengatasi masalah ini.

Ada beberapa cara untuk mengetahui protokol atau koneksi apa yang digunakan suatu aplikasi. Tcpdump dapat menampilkan paket yang datang atau keluar baik antarmuka jaringan nyata maupun virtual seperti pflog dan pfsync. Anda dapat menentukan ekspresi filter untuk menentukan paket mana yang akan ditampilkan dan menghilangkan gangguan jaringan yang asing. Cobalah untuk membuat koneksi jaringan di aplikasi yang diinginkan dan lihat paket yang dikirim. Misalnya:

# tcpdump -nvvvpi fxp0 tcp dan bukan port ssh dan bukan port smtp

23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667: S

4093655771:4093655771(0) menang 5840

1039287798 0,nop,wskala 0> (DF)

Ini adalah paket TCP SYN, paket pertama dari jabat tangan TCP.

Pengirimnya adalah 10.1.2.3 port 65123 (tampak seperti port acak yang tidak memiliki hak istimewa) dan penerimanya adalah 10.2.3.4 port 6667. Penjelasan rinci tentang format keluaran tcpdump dapat ditemukan di halaman manual utilitas. Tcpdump adalah alat paling penting untuk men-debug masalah terkait pf dan sangat penting untuk memahaminya.

Metode lainnya adalah dengan menggunakan fitur logging pf. Dengan asumsi Anda menggunakan opsi 'log' di semua aturan dengan 'blok', maka semua paket yang diblokir oleh pf akan tercermin dalam log. Dimungkinkan untuk menghapus opsi 'log' dari aturan yang berhubungan dengan protokol yang dikenal, misalnya. Hanya paket-paket yang masuk ke port yang tidak diketahui yang akan dicatat dalam log. Coba gunakan aplikasi yang tidak bisa konek dan lihat pflog:

# ifconfig pflog0 ke atas

# tcpdump -netti pflog0

26 Nov 00:02:26.723219 aturan 41/0(pertandingan): blokir sesuai isyarat0:

195.234.187.87.34482 > 62.65.145.30.6667: S 3537828346:3537828346(0) menang

16384 (DF)

Jika Anda menggunakan pflog, daemon yang terus-menerus mendengarkan pflog0 dan menyimpan informasi yang diterima di /var/log/pflog, Anda dapat melihat informasi yang disimpan seperti ini:

# tcpdump -bersih/var/catatan/pflog

Saat mengeluarkan paket pf yang disimpan, Anda dapat menggunakan ekspresi pemfilteran tambahan, misalnya, melihat paket yang diblokir pada input pada antarmuka wi0:

# tcpdump -netttr /var/log/pflog masuk dan blok tindakan dan di wi0

Beberapa protokol, seperti FTP, tidak mudah dilacak karena tidak menggunakan nomor port tetap atau menggunakan beberapa koneksi yang ada bersamaan. Mungkin tidak mungkin untuk mendapatkannya melalui firewall tanpa membuka berbagai port. Untuk protokol individual, ada solusi yang mirip dengan ftp-proxy.

Aturan debug

Jika aturan Anda memblokir protokol tertentu karena Anda tidak membuka port yang benar, itu lebih merupakan masalah desain daripada bug dalam aturan. Namun bagaimana jika Anda melihat bahwa koneksi yang aturannya Anda izinkan diblokir?

Misalnya, set Anda berisi aturan

blok di return-pertama pada $ext_if proto tcp dari port mana pun ke $ext_if ssh

Namun saat Anda mencoba menyambung ke TCP port 22, sambungan diterima! Sepertinya firewall mengabaikan aturan Anda. Sama seperti menyusun teka-teki, ada penjelasan sederhana yang logis dan biasanya sepele untuk hal-hal ini saat pertama kali Anda menemukannya.

Pertama, Anda harus memeriksa semua langkah yang disebutkan sebelumnya. Misalnya, asumsikan firewall sedang berjalan dan berisi aturan yang diberikan di atas. Kekhawatiran kami sebelumnya mungkin tidak benar, namun mudah untuk memeriksanya:

# pfctl -si | status grep

Status: Diaktifkan selama 4 hari 14:03:13Debug: Mendesak

# pfctl -gsr | grep "pelabuhan=ssh"

@14 blok return-pertama di kue0 inet proto tcp dari mana saja ke 62.65.145.30 port = ssh

Hal berikutnya yang kita miliki adalah: koneksi TCP diterima pada port 22 di kue0. Anda mungkin berpikir ini sudah jelas, tetapi ada baiknya untuk memeriksanya. Jalankan tcpdump:

# tcpdump -nvvvi kue0 tcp dan port 22 dan dst 62.65.145.30

Sekarang coba lagi koneksi SSH. Anda akan melihat paket dari koneksi Anda di keluaran tcpdump. Anda mungkin tidak melihatnya, dan ini mungkin karena koneksi sebenarnya tidak melalui kue0, namun melalui antarmuka yang berbeda, yang menjelaskan mengapa aturan tersebut tidak terpicu. Atau Anda mungkin terhubung ke alamat lain. Singkatnya, jika Anda tidak melihat paket ssh, pf juga tidak akan melihatnya, dan mungkin tidak dapat memblokirnya menggunakan aturan yang diberikan dalam masalah kita.

Namun jika Anda melihat paket menggunakan tcpdump, pf akan “melihatnya” juga dan memfilternya. Asumsi berikutnya adalah bahwa aturan pemblokiran tidak hanya harus ada di set (yang telah kita tetapkan), tetapi harus menjadi aturan pencocokan terakhir untuk paket yang diinginkan. Jika ini bukan aturan final, maka jelas keputusan untuk menahan paket tidak dibuat berdasarkan aturan ini.

Dalam kasus apa suatu aturan mungkin bukan aturan terakhir yang cocok? Ada tiga kemungkinan alasan:

A) aturan tidak berfungsi, karena melihat aturan tidak mencapai apa yang kita butuhkan.

Aturan yang ada sebelumnya juga terpicu dan menyebabkan eksekusi dihentikan dengan opsi 'cepat';

B) aturan diproses, tetapi aturan tidak berfungsi karena ketidaksesuaian kriteria individu.

C) aturan diproses, aturan dipicu, tetapi pemrosesan berlanjut dan aturan berikutnya juga dipicu untuk paket tersebut.

Untuk menolak ketiga kasus ini, Anda dapat, dengan melihat kumpulan aturan yang dimuat, secara mental membayangkan memproses paket TCP hipotetis yang tiba di antarmuka kue0 dan port 22. Pilih blok yang akan di-debug. Mulailah merangkak dengan aturan pertama. Apakah itu cocok? Jika ya, tandai. Apakah ada opsi 'cepat'? Jika demikian, maka kita berhenti berkeliling. Jika tidak, lanjutkan dengan aturan berikutnya. Ulangi pemeriksaan hingga ditemukan kecocokan dengan opsi 'cepat' atau akhir dari kumpulan aturan tercapai. Aturan manakah yang terakhir kali cocok? Jika bukan aturan nomor 14, Anda sudah menemukan penjelasan masalahnya.

Mengabaikan aturan secara manual mungkin tampak menyenangkan, namun, jika Anda memiliki pengalaman yang cukup, hal ini dapat dilakukan dengan cukup cepat dan dengan tingkat keandalan yang tinggi. Jika kumpulannya cukup besar, Anda dapat menguranginya untuk sementara. Simpan salinan daftar aturan sebenarnya dan hapus entri yang menurut Anda tidak akan mempengaruhi hasilnya. Unduh set ini dan uji lagi. Jika koneksi sekarang diblokir, maka aturan yang tampaknya tidak terkait dengan paket yang Anda cari bertanggung jawab untuk kasus A atau B. Tambahkan aturan satu per satu, ulangi pengujian hingga Anda menemukan yang Anda perlukan. Jika koneksi masih dilewati setelah menghapus aturan yang tidak mempengaruhinya, ulangi traversal mental dari himpunan yang dikurangi.

Metode lain adalah dengan menggunakan kemampuan logging pf untuk mengidentifikasi kasus A atau C. Tambahkan 'log' ke semua aturan dengan 'pass quick' sebelum aturan ke-14. Tambahkan 'log' ke semua aturan dengan 'pass' setelah aturan ke-14. Jalankan tcpdump untuk antarmuka pflog0 dan buat koneksi ssh. Anda akan melihat aturan mana selain aturan ke-14 yang dipicu terakhir kali pada paket Anda. Jika tidak ada apa pun di log, maka terjadi kasus B.

Melacak koneksi melalui firewall

Ketika koneksi melewati firewall, paket tiba di satu antarmuka dan dikirim melalui antarmuka kedua. Tanggapan datang ke antarmuka kedua dan menuju ke antarmuka pertama. Oleh karena itu, koneksi bisa gagal dalam keempat kasus ini.

Pertama, Anda harus mencari tahu yang mana dari empat kasus tersebut yang merupakan masalahnya. Jika Anda mencoba membuat sambungan, Anda akan melihat paket TCP SYN pada antarmuka pertama menggunakan tcpdump. Anda juga akan melihat keluaran paket TCP SYN yang sama dari antarmuka kedua. Jika Anda tidak melihatnya, maka kami menyimpulkan bahwa pf memblokir paket masuk pada antarmuka pertama, atau paket keluar pada antarmuka kedua.

Jika pengiriman SYN tidak diblokir, Anda akan melihat SYN+ACK masuk ke antarmuka kedua dan keluar dari antarmuka pertama. Jika tidak, pf memblokir SYN+ACK pada beberapa antarmuka.

Tambahkan opsi 'log' ke aturan yang mengizinkan SYN dan SYN+ACK di kedua antarmuka, serta aturan yang harus memblokirnya. Coba lagi koneksi dan periksa pflog. Ini harus menjelaskan dalam kasus apa pemblokiran itu terjadi dan berdasarkan aturan apa.

Men-debug status koneksi

Alasan paling umum mengapa paket pf diblokir adalah karena ada aturan pemblokiran yang berlebihan di set. Aturan pencocokan terakhir yang sesuai dapat ditemukan dengan menambahkan opsi 'log' ke semua aturan yang berpotensi berdampak dan mendengarkan antarmuka pflog.

Dalam sejumlah kecil kasus, pf secara diam-diam menjatuhkan paket berdasarkan non-aturan, dan di sini menambahkan 'log' ke semua aturan tidak akan menyebabkan paket yang dijatuhkan berakhir di pflog. Seringkali sebuah paket hampir, tapi tidak seluruhnya, cocok dengan entri negara.

Ingatlah bahwa untuk setiap paket yang diproses, filter paket memindai tabel status. Jika entri yang cocok ditemukan, paket akan segera diizinkan masuk tanpa menyebabkan kumpulan aturan diproses sendiri.

Entri tabel keadaan berisi informasi khusus untuk satu koneksi.

Setiap entri memiliki kunci unik. Kunci ini terdiri dari beberapa nilai yang membatasi masa pakai koneksi menjadi konstan sepanjang waktu. Di sini mereka:

• Jenis alamat (Ipv4 atau Ipv6)
• Alamat sumber
• Alamat penerima
• Protokol (TCP UDP)
• Pelabuhan sumber
• Pelabuhan penerima

Kunci ini digunakan untuk semua paket milik koneksi yang sama, dan paket dari koneksi berbeda akan selalu memiliki kunci berbeda.

Ketika entri tabel status dibuat menggunakan opsi 'pertahankan status' dari aturan, entri koneksi disimpan menggunakan kunci koneksi. Batasan penting untuk tabel status adalah semua kunci harus unik. Itu. tidak boleh ada dua catatan dengan kunci yang sama.

Mungkin tidak terlihat jelas bahwa dua host yang sama tidak dapat membuat beberapa koneksi yang hidup berdampingan menggunakan alamat, protokol, dan port yang sama, tetapi ini adalah properti mendasar dari TCP dan UDP. Faktanya, tumpukan TCP/IP hanya dapat mengaitkan paket individual dengan soketnya dengan melakukan pemilihan berdasarkan alamat dan port.

Meskipun sambungan ditutup, pasangan alamat dan port yang sama tidak dapat langsung digunakan kembali. Peralatan jaringan nantinya dapat mengirimkan paket yang ditransmisikan ulang, dan jika tumpukan TCP/IP penerima salah mengira paket tersebut sebagai paket dari koneksi yang baru dibuat, hal ini akan mengganggu atau bahkan memutus koneksi baru. Karena alasan ini, kedua host harus menunggu jangka waktu tertentu, yang disebut 2MSL ("dua kali masa hidup segmen maksimum"), sebelum dapat menggunakan alamat dan port yang sama lagi untuk sambungan baru.

Anda dapat mengamati properti ini dengan secara manual membuat beberapa koneksi ke host yang sama. Misalnya, memiliki server web yang berjalan pada 10.1.1.1 dan port 80, dan terhubung dua kali dengan 10.2.2.2. menggunakan nc:

$ nc -v 10.1.1.1 80 & nc -v 10.1.1.1 80

Koneksi ke port 10.1.1.1 80 berhasil!

Saat koneksi terbuka, Anda dapat menggunakan netstat di klien atau server untuk menampilkan informasi tentang koneksi berikut:

$ status bersih -n | ambil 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 DIDIRIKAN

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 DIDIRIKAN

Seperti yang Anda lihat, klien telah memilih dua port sumber yang berbeda (acak), jadi ini tidak melanggar persyaratan keunikan utama.

Anda dapat memberitahu nc untuk menggunakan port sumber tertentu dengan opsi -p:

$ nc -v -p 31234 10.1.1.1 80 & nc -v -p 31234 10.1.1.1 80

Koneksi ke port 10.1.1.1 80 berhasil!

nc: pengikatan gagal: Alamat sudah digunakan

Tumpukan TCP/IP klien mencegah keunikan kunci dikompromikan. Beberapa implementasi tumpukan TCP/IP yang jarang dan bermasalah tidak mengikuti aturan ini, dan oleh karena itu, seperti yang akan segera kita lihat, pf akan memblokir koneksi mereka jika keunikan kunci dilanggar.

Mari kita kembali ke tempat pf menanyakan tabel status saat paket mulai difilter. Permintaan terdiri dari dua langkah. Permintaan pertama dibuat untuk menemukan entri dalam entri tabel dengan kunci yang sesuai dengan protokol, alamat, dan port paket. Pencarian akan dilakukan untuk paket-paket yang menuju ke segala arah. Anggaplah paket berikut membuat entri di tabel status:

masukTCPdari 10.2.2.2:28054hingga 10.1.1.1:80

Kueri tabel akan menemukan entri berikut dalam tabel status:

TCP masuk dari 10.2.2.2:28054 hingga 10.1.1.1:80

TCP keluar dari 10.1.1.1:80 hingga 10.2.2.2:28054

Entri dalam tabel mencakup informasi tentang arah (masuk atau keluar) paket pertama yang membuat entri tersebut. Misalnya, entri berikut tidak akan menghasilkan kecocokan:

keluarTCPdari 10.2.2.2:28054hingga 10.1.1.1:80

masukTCPdari 10.1.1.1:80ke 10.2.2.2:28054

Alasan pembatasan ini tidak jelas, namun cukup sederhana. Bayangkan Anda hanya memiliki satu antarmuka dengan alamat 10.1.1.1, di mana server web mendengarkan pada port 80. Ketika klien 10.2.2.2 terhubung menggunakan port keluar 28054 yang dipilih secara acak, paket koneksi pertama tiba di antarmuka Anda dan semua respons keluar Anda seharusnya akan berubah dari 10.1.1.1:80 menjadi 10.2.2.2:28054. Anda tidak akan mengizinkan paket keluar dari 10.2.2.2:28054 hingga 10.1.1.1:80, karena paket tersebut tidak ada artinya.

Jika firewall Anda dikonfigurasi untuk dua antarmuka, maka dengan mengamati paket yang melewatinya, Anda akan melihat bahwa setiap paket yang masuk ke antarmuka pertama keluar dan melalui antarmuka kedua. Jika Anda membuat entri keadaan di mana paket awal tiba pada antarmuka pertama, maka entri tersebut akan mencegah paket yang sama meninggalkan antarmuka kedua karena salah arah.

Ketika upaya untuk menemukan paket di antara entri dalam tabel status gagal, daftar aturan filter akan dilalui. Anda harus secara khusus mengizinkan paket untuk melewati antarmuka kedua dengan aturan terpisah. Anda mungkin menggunakan 'keep state' dalam aturan ini sehingga entri kedua dalam tabel status mencakup seluruh koneksi dan antarmuka kedua.

Anda mungkin bertanya-tanya bagaimana mungkin membuat catatan kedua dalam tabel jika kami baru saja menjelaskan bahwa catatan harus memiliki kunci unik. Penjelasannya di sini adalah bahwa catatan tersebut juga berisi informasi tentang arah koneksi, dan kombinasinya dengan data lainnya harus unik.

Sekarang kami juga akan dapat menjelaskan perbedaan antara koneksi gratis dan koneksi terikat antarmuka. Secara default, pf membuat entri yang tidak terikat pada antarmuka apa pun. Oleh karena itu, jika Anda mengizinkan koneksi pada satu antarmuka, paket yang terkait dengan koneksi tersebut dan entri tabel yang cocok (termasuk informasi tentang arah paket!) melewati antarmuka mana pun. Dalam instalasi sederhana dengan perutean statis, ini adalah perhitungan yang lebih teoretis. Pada prinsipnya, Anda tidak akan melihat paket dari koneksi yang sama tiba di banyak antarmuka dan paket respons juga keluar dari banyak antarmuka. Namun, dengan perutean dinamis hal ini dimungkinkan. Anda dapat mengikat catatan negara bagian ke antarmuka tertentu menggunakan pengaturan global 'setel kebijakan negara bagian jika terikat' atau opsi per aturan 'pertahankan status (jika terikat)'. Dengan cara ini Anda akan yakin bahwa paket hanya akan dicocokkan dengan catatan dari antarmuka yang membuat catatan ini.

Jika antarmuka terowongan digunakan, maka koneksi yang sama melewati firewall beberapa kali. Misalnya, paket pertama dari suatu koneksi mungkin pertama-tama melewati antarmuka A, lalu melalui B, lalu C dan akhirnya meninggalkan kita melalui antarmuka D. Biasanya paket-paket tersebut akan dienkapsulasi pada antarmuka A dan D dan didekapsulasi pada B dan C, jadi pf melihat paket protokol yang berbeda dan Anda dapat membuat 4 entri berbeda di tabel status. Tanpa enkapsulasi, paket tidak akan berubah pada keempat antarmuka dan Anda tidak akan dapat menggunakan beberapa fitur, seperti terjemahan alamat atau modulasi nomor urut TCP, karena ini akan menyebabkan munculnya kunci yang bertentangan di tabel status. Sampai Anda memiliki instalasi lengkap yang mencakup antarmuka dengan terowongan dan kesalahan yang di-debug seperti "pf: src_tree insert failed", Anda tidak akan dapat menganggap instalasi Anda cukup berhasil. Mari kita kembali ke query tabel keadaan yang dibuat untuk setiap paket sebelum memeriksa aturannya. Kueri harus mengembalikan satu rekaman dengan kunci yang cocok, atau tidak menghasilkan apa pun. Jika kueri tidak menghasilkan apa pun, daftar aturan akan dilewati.

Jika entri ditemukan, langkah kedua untuk paket TCP sebelum dianggap milik koneksi tertentu dan disaring adalah memeriksa nomor urutnya.

Ada sejumlah besar serangan TCP di mana penyerang mencoba mengendalikan koneksi antara dua host. Dalam kebanyakan kasus, penyerang tidak berada di jalur antar host, dan oleh karena itu tidak dapat menguping paket sah yang dikirim oleh host. Namun, dia dapat mengirim paket ke salah satu host, meniru paket lawan bicaranya, dengan melakukan spoofing (“spoofing”) - memalsukan alamat pengirim. Tujuan penyerang mungkin untuk mencegah terciptanya koneksi antar host, atau mengakhiri koneksi yang sudah ada (menyebabkan penolakan layanan), atau membuat download berbahaya pada koneksi.

Agar serangan berhasil, penyerang harus “menebak” beberapa parameter koneksi dengan benar, seperti alamat/port sumber dan tujuan. Dan untuk protokol yang tersebar luas, hal ini mungkin tidak sesulit kelihatannya. Jika penyerang mengetahui alamat host dan salah satu port (karena kita berbicara tentang layanan umum), dia hanya perlu “menebak” satu port. Bahkan jika klien menggunakan port sumber yang benar-benar acak (yang tidak selalu benar), penyerang hanya perlu melintasi 65536 port dalam waktu singkat. (Dalam kebanyakan kasus, port genap (65536-1024), yaitu hanya port yang tidak memiliki hak istimewa - catatan penerjemah))

Namun yang benar-benar sulit ditebak oleh penyerang adalah nomor urut yang benar (dan konfirmasinya). Jika kedua host memilih nomor urut awal secara acak (atau Anda menggunakan modulasi nomor urut untuk host yang memiliki generator ISN (Initial Sequence Number) yang lemah), maka penyerang tidak akan dapat menemukan nilai yang sesuai pada waktu yang tepat dalam koneksi. .

Selama adanya koneksi TCP yang valid, nomor urut (dan pengakuan) untuk masing-masing paket berubah sesuai dengan aturan tertentu.

Misalnya, jika host mengirimkan beberapa segmen data dan penerimanya mengakui penerimaannya, maka tidak ada alasan mengapa pengirim harus mengirimkan data segmen itu lagi. Namun pada kenyataannya, upaya untuk menimpa sebagian informasi yang sudah diterima oleh host bukanlah pelanggaran terhadap protokol TCP, meskipun ini mungkin merupakan jenis serangan.

pf menggunakan aturan untuk menentukan rentang terkecil untuk nomor urut yang sah. Secara umum, pf hanya dapat menentukan identitas secara akurat 30.000 dari 4294967296 nomor urut yang mungkin pada waktu tertentu dalam suatu sambungan. Hanya jika nomor urut dan pengakuan disertakan dalam jendela ini, pf akan yakin bahwa paket tersebut sah dan akan mengizinkannya lewat.

Jika entri yang sesuai ditemukan selama kueri terhadap tabel status, langkah selanjutnya memeriksa nomor urut paket yang disimpan dalam tabel untuk melihat apakah nomor tersebut berada dalam kisaran nilai yang memungkinkan. Jika perbandingan gagal, pf akan menghasilkan pesan "BAD state" dan membuang paket tanpa mengevaluasi aturannya. Ada dua alasan mengapa perbandingan dengan aturan mungkin tidak terjadi: hampir pasti akan terjadi kesalahan karena melewatkan paket, karena jika menghitung himpunan akan menghasilkan aturan mengenai suatu opsi "keep state" dan pf tidak akan dapat mengambil keputusan dan membuat record baru karena hal ini akan menyebabkan konflik kunci dalam tabel.

Untuk melihat dan mencatat pesan "BAD state", Anda perlu mengaktifkan mode debugging menggunakan perintah:

$ pfctl -xm

Pesan debug dikirim ke konsol secara default, dan syslogd juga menulisnya ke /var/log/messages. Cari pesan yang dimulai dengan "pf":

hal:BURUKnegara:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lihat=1185380879tinggi=1185380879menang=33304modulator=0skala = 1]

4:4 Seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631

dir=keluar,fwd

pf: Status kegagalan pada: 1 |

Pesan-pesan ini selalu datang berpasangan. Pesan pertama menunjukkan entri tabel keadaan pada saat paket diblokir dan nomor urut paket yang menyebabkan kesalahan. Entri kedua menampilkan ketentuan yang dilanggar.

Di akhir pesan pertama, Anda akan melihat apakah catatan status dibuat untuk paket masuk (dir=in) atau keluar (dir=out), dan apakah paket yang diblokir bergerak ke arah yang sama (dir=,fwd ) atau arah sebaliknya (dir=,rev) ).

Entri dalam tabel berisi tiga alamat: pasangan port, dua di antaranya selalu sama satu sama lain, jika koneksi belum mengalami konversi nat, rdr, atau bnat. Untuk koneksi keluar, sumber paket ditampilkan di sebelah kiri dan tujuan paket di sebelah kanan. Jika sambungan keluar melibatkan terjemahan alamat sumber, pasangan di tengah menunjukkan sumber setelah terjemahan. Untuk koneksi masuk, sumber berada di sisi kanan output dan alamat tujuan berada di tengah. Jika koneksi masuk mengalami penerjemahan alamat tujuan, pasangan ip/port di sebelah kiri menunjukkan tujuan setelah terjemahan dilakukan. Format ini cocok dengan keluaran pfctl -ss, hanya saja pfctl menunjukkan arah paket menggunakan panah.

Pada output Anda dapat melihat nomor urut host saat ini dalam tanda kurung siku. Jadi nilai “4:4” berarti koneksi telah terjalin sepenuhnya (nilai yang lebih kecil lebih mungkin terjadi pada tahap pembuatan koneksi, nilai yang lebih besar lebih mungkin terjadi pada saat koneksi ditutup)."A" berarti paket yang diblokir memiliki flag ACK yang disetel (seperti pada output flag tcpdump), diikuti dengan nilai nomor urut (seq=) dan (ack=) dalam paket yang diblokir dan panjang muatan paket - panjang data (len =). Askkew adalah bagian dari representasi internal data dalam tabel, hanya digunakan untuk nilai yang tidak sama dengan nol.

Entri "pkts=930:631" berarti cocok dengan 940 paket yang berjalan dalam arah yang sama dengan paket yang menyebabkan entri tersebut dibuat, dan 631 paket dalam arah berlawanan. Penghitung ini akan sangat berguna ketika memecahkan masalah pengaturan koneksi; jika salah satunya nol, ini akan bertentangan dengan harapan Anda bahwa paket di kedua arah cocok dengan entri tersebut.

Pesan berikut akan berisi daftar satu atau lebih nomor. Setiap angka mewakili pengujian di mana kesalahan terjadi:

1. Ukuran jendela paket melebihi ukuran maksimum penerima (seq + len > high)
2. paket berisi data yang sudah dikirimkan (seq< lo - win)
3. ackskew kurang dari nilai minimum
4. ackskew lebih besar dari nilai maksimum
5. sama seperti pada (1), tetapi dengan perbedaan (seq + len > high + win)
6. sama seperti pada (2), tetapi (seq< lo - maximum win)

Untungnya, pesan "keadaan BURUK" tidak berlaku untuk lalu lintas sehari-hari yang sebenarnya, dan memeriksa nomor urut pf menghindari sebagian besar anomali. Jika Anda melihat pesan-pesan ini muncul secara sporadis dan tidak melihat banyak koneksi yang hang, Anda dapat mengabaikannya. Ada banyak implementasi TCP/IP yang berjalan di Internet, dan beberapa di antaranya terkadang dapat menghasilkan paket yang salah.

Namun, masalah kelas ini dapat dengan mudah didiagnosis dengan munculnya pesan "keadaan buruk" yang hanya muncul dalam kasus tersebut.

Membuat Catatan NegaraTCP berdasarkan inisialSYN ke paket.

Idealnya, catatan negara harus dibuat ketika paket SYN pertama terjadi.

Anda dapat memaksakan penggunaan aturan ini dengan menggunakan prinsip:

“Gunakan opsi “flags S/SA” di semua aturan “pass proto tcp keep state””

Hanya paket SYN awal (dan hanya paket ini) yang memiliki flag SYN yang disetel dan ACK dikumpulkan. Ketika opsi "pertahankan status" diterapkan hanya pada paket SYN awal, hanya paket tersebut yang akan membuat entri dalam tabel status. Dengan demikian, setiap entri yang ada di tabel status akan diturunkan dari paket SYN awal.

Alasan pembuatan catatan hanya untuk paket awal adalah ekstensi protokol TCP yang disebut “penskalaan jendela” yang didefinisikan dalam RFC1323. Bidang header TCP yang digunakan untuk mengumumkan ukuran jendela yang diterima terlalu kecil untuk link komunikasi berkecepatan tinggi saat ini. Implementasi TCP/IP modern lebih memilih untuk menggunakan ukuran jendela yang lebih besar daripada yang dapat ditampung dalam bidang yang ada. Penskalaan ukuran jendela berarti bahwa semua ukuran jendela yang diketahui dari host penerima harus dikalikan dengan nilai tertentu yang ditentukan oleh penerima, bukan diambil sendiri. Agar skema ini berfungsi, kedua host harus mendukung ekstensi dan menunjukkan satu sama lain kemampuan mereka untuk mengimplementasikannya selama fase pembuatan koneksi (“jabat tangan”) menggunakan opsi TCP. Opsi ini hanya ada pada paket SYN dan SYN+ACK awal. Hanya jika masing-masing paket ini berisi opsi maka kesepakatan bersama akan berhasil dan ukuran jendela semua paket berikutnya akan dikalikan dengan sebuah faktor.

Jika pf "tidak mengetahui" penskalaan jendela yang digunakan, ia akan mengambil nilai yang diberikan tanpa faktor, dan menghitung ukuran jendela untuk nilai nomor urut yang dapat diterima akan salah. Biasanya, host menyediakan ukuran jendela kecil pada awal koneksi dan meningkatkannya seiring kemajuan koneksi. Tidak menyadari adanya faktor-faktor yang mengubah ukuran jendela, pf pada suatu saat akan mulai memblokir paket, karena ia akan percaya bahwa salah satu host sedang mencoba untuk melewati ukuran jendela maksimum yang disediakan oleh “lawan bicara”. Dampaknya mungkin lebih atau kurang terlihat. Terkadang, host akan merespons kehilangan paket dengan berpindah ke apa yang disebut. "mode pemulihan kerugian" dan akan mengiklankan ukuran jendela yang lebih kecil. Setelah pf mengirimkan kembali paket yang dijatuhkan pertama kali, ukuran jendela akan semakin bertambah, hingga pf akan mulai memblokirnya lagi. Manifestasi eksternalnya mungkin berupa koneksi sementara yang terhenti dan kinerja rendah. Mungkin juga koneksi terhenti atau disetel ulang sepenuhnya karena waktu tunggu habis.

Tapi pf tahu tentang kemungkinan penskalaan windows dan mendukung kemungkinan ini. Namun, prasyarat untuk membuat entri tabel status pada paket SYN pertama adalah pf dapat mengaitkan dua paket pertama koneksi dengan entri tabel. Dan karena pencocokan penuh koefisien ukuran jendela hanya terjadi pada dua paket pertama, tidak ada metode yang dapat diandalkan untuk menentukan koefisien ini setelah koneksi dinegosiasikan.

Di masa lalu, penskalaan ukuran jendela tidak banyak digunakan, namun hal ini berubah dengan cepat. Baru-baru ini Linux mengaktifkan opsi ini secara default. Jika Anda mengalami kesulitan dengan koneksi yang terhenti, terutama dengan kombinasi host tertentu, dan melihat pesan "status BURUK" terkait dengan koneksi ini, periksa apakah Anda benar-benar membuat entri tabel status pada paket pertama koneksi.

Anda dapat menentukan apakah pf menggunakan opsi penskalaan untuk koneksi dari output pfctl:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 DIDIRIKAN: DIDIRIKAN

skala 0skala 1

Jika ada entri "wscale x" yang tercetak pada baris kedua (meskipun x adalah nol), pf akan membaca bahwa ia mengetahui bahwa koneksi menggunakan penskalaan.

Metode sederhana lainnya untuk mengidentifikasi masalah yang terkait dengan penskalaan adalah dengan menonaktifkan sementara dukungan penskalaan dan memutar ulang situasinya. Pada OpenBSD, penggunaan penskalaan dapat dikontrol dengan opsi sysctl:

$ sistembersih.inet.tcp.rfc1323

bersih.inet.tcp.rfc1323=1

$ sistem -wsistembersih.inet.tcp.rfc1323=0

bersih.inet.tcp.rfc1323: 1 -> 0

Masalah serupa muncul ketika Anda membuat entri dalam tabel status untuk paket selain SYN awal dan menggunakan opsi atau siaran "mulate state". Dalam kedua kasus tersebut, siaran terjadi pada awal koneksi. Jika paket pertama tidak diterjemahkan, tranching paket berikutnya biasanya membuat pihak penerima enggan dan menyebabkan balasan yang dikirim diblokir oleh pf dengan pesan "BAD state".

Metodologi pengujian

Pengujian dilakukan pada PC eksperimental yang menjalankan Windows XP berlisensi dengan SP1 diinstal (pengujian dilakukan dalam kondisi ideal - "sistem operasi + Firewall" untuk mengecualikan pengaruh program lain terhadap kemurnian percobaan). Utilitas APS digunakan sebagai indikator keberhasilan akses terhadap layanan. Pengaruh eksternal berikut digunakan:

• pemindai XSpider 6.5 dan 7.0
• Pemindai Keamanan Jaringan Retina 4.9
• beberapa pemindai desain saya.

Selain itu, sniffer CommView 4.1 digunakan (sebagai sarana pemantauan lalu lintas jaringan dan sebagai utilitas untuk menghasilkan dan mengirim paket dengan berbagai ketidakteraturan struktur). Disebut tipe umum banjir, utilitas untuk mensimulasikan program Trojan.

Pada PC uji, IE 6, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1 digunakan sebagai sarana mengakses jaringan dan Internet. Selain itu, pengujian ini melibatkan simulator program Trojan dan program Trojan / Backdoor asli dari koleksi saya (khususnya Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), jaringan / virus email ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), pengunduh Trojan Downloader (khususnya TrojanDownloader.IstBar) dan komponen SpyWare. Tugas utama pengujian ini adalah mencoba melihat Firewall dari sudut pandang pengguna, untuk mencatat kekuatan dan kelemahannya dari sudut pandang saya.

Teknologi Kerio WinRoute Pro v4.2.5

Instalasi dan penghapusan instalasi:
Ini berjalan tanpa masalah.
Instalasi dengan pengaturan default, tidak ada aturan - hanya NAT yang valid. Bekerja di jaringan - tidak ada masalah, hasil pemindaian - APS tidak menunjukkan status alarm, pemindai percaya bahwa semua port ditutup. Winroute sendiri tidak mengeluarkan alarm dan tidak mengidentifikasi fakta pemindaian secara visual.

Outpost Firewall Pro 2.1 Bangun 303.4009 (314)

Instalasi dan penghapusan instalasi:
Instalasi di bawah XP berlangsung tanpa masalah; saat startup, mode pelatihan diaktifkan.

ZoneLabs ZoneAlarm Pro dengan Pemfilteran Web 4.5.594.000 - Firewall Pribadi

Instalasi dan penghapusan instalasi:
Selama instalasi, XP crash ketika mencoba untuk memulai setelah instalasi. Setelah reboot semuanya berfungsi dengan baik.

Di Penjaga 3.22>

Instalasi dan penghapusan instalasi:
Instalasi dan uninstall tidak menimbulkan masalah khusus

Keuntungan:

1. Firewall berukuran kecil dan memiliki solusi menarik dalam hal antarmuka - dirancang sebagai panel yang ditempatkan di bagian atas layar

Kekurangan dan fitur:

1. Dalam mode pelatihan, ini rentan - dari saat permintaan untuk membuat aturan dikeluarkan hingga dibuat, ia meneruskan paket di kedua arah
2. Antarmukanya sedikit bermasalah saat menggambar ulang jendela

Peringkat keseluruhan:
Firewall Sederhana, namun cukup fungsional

Firewall Pribadi Kerio 4

Instalasi dan penghapusan instalasi:
Penginstalan berlangsung tanpa masalah, penghapusannya "bersih" - tidak ada masalah yang terlihat setelah penghapusan instalasi.

Keamanan Internet Norton 2004 (NIS)

Instalasi dan penghapusan instalasi: Instalasi tidak menimbulkan masalah, tetapi dari semua yang dianalisis, installer adalah yang paling rumit.

Firewall Koneksi Internet, ICF - Firewall bawaan Windows XP

Instalasi dan penghapusan instalasi: Tidak diperlukan instalasi, ini adalah alat XP standar. Pengaktifan dilakukan di pengaturan adaptor jaringan. Secara default, ICF beroperasi dalam mode keamanan maksimum dan (ini adalah hasil pengamatan saya) prinsip operasinya adalah sebagai berikut: permintaan aplikasi dilepaskan secara eksternal, dan hanya paket yang datang sebagai tanggapan atas permintaan saya yang diterima secara eksternal (permintaan -korespondensi tanggapan disimpan dengan jelas dalam bentuk tabel dinamis). Jadi, ketika memindai port pada komputer dengan ICF diaktifkan, tidak ada satu pun port yang terbuka (ini logis - paket pemindai port tidak akan terlewatkan, karena tidak ada yang memintanya). Situasi serupa terjadi dengan berbagai macam "nuklir" yang didasarkan pada pengiriman paket non-standar

Firewall Koneksi Internet, ICF - firewall bawaan untuk Windows XP SP2

Instalasi dan penghapusan instalasi: Tidak diperlukan instalasi, ini adalah alat XP standar (termasuk dalam SP2 untuk XP). Pengaktifan dilakukan di pengaturan adaptor jaringan. Perlu dicatat bahwa ketika menginstal SP2 atau ketika menginstal XP dengan SP2 terintegrasi, selain Firewall, pusat keamanan muncul di sistem, yang dapat menampilkan pengaturan ICF

Sygate Personal Firewall Pro 5.5 build 2525

Instalasi dan penghapusan instalasi:

ISS BlackIce 3.6.cci

Instalasi dan penghapusan instalasi: Menginstal dan menghapus instalasi program terjadi tanpa masalah, tetapi selama instalasi terjadi kesalahan di perpustakaan ikernel. Kesalahan yang sama terjadi saat pencopotan pemasangan. Terjadinya error ini tidak mempengaruhi proses install dan uninstall program. Penginstal tidak memerlukan reboot sistem, hal yang tidak biasa untuk Firewall

Firewall Visnetik 2.2

Instalasi dan penghapusan instalasi: Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Setelah instalasi, diperlukan reboot.

Lihat dan hentikan firewall pribadi 2.05

Instalasi dan penghapusan instalasi: Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Setelah instalasi, diperlukan reboot. Ia menginstal drivernya sendiri agar berfungsi.

Kaspersky AntiHacker 1.5

Instalasi dan penghapusan instalasi: Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Setelah instalasi, diperlukan reboot.

Firewall Pribadi Kecil Pro 6.0

Instalasi dan penghapusan instalasi:
Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Setelah instalasi, diperlukan reboot.

McAfee Personal Firewall Ditambah 6.0 Bangun 6014

Instalasi dan penghapusan instalasi:
Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Setelah instalasi, diperlukan reboot.

R-Firewall 1.0 Bangun 43

Instalasi dan penghapusan instalasi:
Menginstal program dan menghapus instalasinya terjadi tanpa masalah. Ukuran distribusinya kecil (3,8 MB), Anda dapat menyesuaikan komposisi produk. Pekerjaannya cukup stabil, tidak ada kerusakan atau kemacetan yang terlihat pada PC referensi

Kesimpulan dan kesimpulan umum

Jadi, mari kita rangkum hasil tesnya. Faktanya, tes tersebut mengkonfirmasi gagasan teoretis saya tentang keadaan masalahnya:

1. Firewall perlu dikonfigurasi. Semua Firewall yang diuji berfungsi dengan baik, tetapi hanya setelah konfigurasi (pelatihan, membuat pengaturan secara manual - tidak masalah). Menggunakan Firewall yang tidak dikonfigurasi dapat menyebabkan lebih banyak kerugian daripada manfaat (ini akan memungkinkan paket berbahaya masuk dan, sebaliknya, akan mengganggu program yang berguna);
2. Setelah menyiapkan Firewall dan IDS, Anda perlu mengujinya- Ini juga merupakan kesimpulan yang cukup jelas, namun tetap penting. Saya mengambil langkah pertama untuk membuat penguji - ini adalah utilitas APS. Ada dua lagi yang tersisa - simulator program Trojan (yaitu utilitas yang akan melakukan upaya aman bagi pengguna untuk "membobol" Firewall dari dalam (tentu saja, serangan akan dijelaskan oleh database dan akan dilakukan di komputer pengguna). perintah di bawah kendalinya), yang memungkinkan untuk mengamati reaksi Firewall dan IDS) dan utilitas untuk pemindaian port ekspres dan melakukan serangan dasar (pada dasarnya APS justru sebaliknya - mereka dapat memiliki basis port yang sama). Saya sudah mengembangkan utilitas ini - kehadirannya di gudang pengguna akan memungkinkan adanya semacam "kontrol instrumental".
3. Personal Firewall rentan terhadap malware yang dijalankan dari konteks program yang berguna. Kesimpulan - setidaknya hilangkan panel "kiri" yang berbeda dan BHO lain dari browser dan email!! Sebelum memasang plugin, panel, utilitas ekstensi, dll. Anda perlu berpikir sepuluh kali tentang kebutuhannya, karena... mereka bukan proses sistem operasi yang terpisah dan dijalankan dari konteks program induk. Program Trojan mudah dideteksi oleh Firewall pribadi - ia "melihat" bahwa proses tertentu (misalnya, bo2k.exe) mencoba untuk mulai mendengarkan pada port xxxxx atau berkomunikasi dengan host tertentu - permintaan izin dikeluarkan, pengguna mulai mencari tahu jenis "bo2k.exe" itu " dan Backdoor tertangkap. Namun jika program Trojan bekerja dari konteks browser, maka hampir pasti tidak ada yang akan memperhatikan akses browser ke Internet. Ada program Trojan seperti itu, contoh terdekat adalah TrojanDownloader.IstBar - diinstal persis seperti panel IE (tentu saja tidak ada dalam proses, juga tidak ada dalam daftar autorun);
4. Banyak Firewall pribadi yang terlihat sebagai proses sistem operasi dan dapat dihentikan oleh virus. Kesimpulan - kerja Firewall perlu dipantau dan penghentiannya yang tiba-tiba dapat menjadi sinyal bahwa virus telah menembus PC;
5. Beberapa Firewall (misalnya Kerio) mengizinkan kendali jarak jauh- fungsi kendali jarak jauh harus dinonaktifkan atau dilindungi kata sandi.

Pengujian komparatif terhadap 21 firewall populer untuk kualitas perlindungan terhadap serangan yang datang dari dalam sistem. Pengujian tersebut menguji perlindungan menggunakan 64 utilitas pengujian yang dikembangkan secara khusus yang memeriksa perlindungan proses dari penghentian, perlindungan dari serangan internal standar, perlindungan dari kebocoran non-standar, dan perlindungan dari teknik non-standar untuk menembus mode kernel.

Selain antivirus, firewall merupakan salah satu komponen utama keamanan komputer. Namun, tidak seperti antivirus, pengujian objektif terhadap kinerja firewall jarang dilakukan. Kami mencoba menutup kesenjangan ini dengan melakukan pengujian firewall untuk perlindungan terhadap serangan internal pada tahun 2011 dan 2012 dan pengujian IDS/IPS pribadi untuk perlindungan terhadap serangan terhadap aplikasi yang rentan. Tahun ini, kami memutuskan untuk memperluas daftar metode yang digunakan dan mengulangi pengujian firewall untuk perlindungan terhadap serangan internal guna melihat bagaimana hasil produk populer menurut kriteria ini telah berubah seiring waktu.

Apa tujuan pengujian ini atau fungsi apa yang dilakukan firewall? Menurut definisi standar Internet [RFC3511] (2003), firewall adalah sistem yang mengimplementasikan fungsi penyaringan paket jaringan sesuai dengan aturan yang ditentukan untuk membedakan lalu lintas antar segmen jaringan. Namun, dengan semakin kompleksnya serangan malware dan hacker, tugas firewall asli telah dilengkapi dengan modul fungsional baru. Hampir tidak mungkin membayangkan firewall lengkap tanpa modul HIPS (memantau kejadian sistem, memantau integritas sistem, dll.).

Tugas utama firewall modern adalah memblokir komunikasi jaringan yang tidak sah (selanjutnya disebut serangan), dibagi menjadi internal dan eksternal. Ini termasuk:

Serangan eksternal pada sistem yang dilindungi firewall:

• diprakarsai oleh peretas;
• diprakarsai oleh kode berbahaya.

• diprakarsai oleh aplikasi yang tidak tepercaya (kode berbahaya);
• diprakarsai oleh aplikasi yang aktivitas jaringannya secara eksplisit dilarang oleh aturan.

Selain itu, produk yang dapat diklasifikasikan sebagai firewall pribadi murni dalam formulasi klasik tahun 2003 telah hampir menghilang dari pasar. Mereka telah digantikan oleh produk kompleks untuk melindungi komputer pribadi, yang tentu saja menyertakan komponen firewall.

Pengujian firewall untuk perlindungan terhadap serangan eksternal melibatkan pemeriksaan kualitas perlindungan terhadap serangan yang datang dari dalam sistem. Tes ini dilakukan di bidang-bidang berikut:

1. Memeriksa perlindungan proses dari penghentian.
2. Perlindungan terhadap serangan internal standar.
3. Menguji perlindungan terhadap kebocoran non-standar.
4. Menguji perlindungan terhadap teknik non-standar untuk menembus mode kernel.

Dibandingkan pengujian sebelumnya, jumlah serangan yang digunakan telah meningkat secara signifikan - dari 40 menjadi 64. Sistem operasi yang harus dilindungi oleh produk yang diuji juga mengalami perubahan. Pada pengujian sebelumnya adalah Windows XP, dan pada pengujian ini adalah Windows 7 x32. Tes serupa juga direncanakan pada akhir tahun untuk sistem operasi Windows 7 x64.

Perkenalan

Pengujian ini melibatkan 21 program perlindungan komprehensif yang populer (kelas Keamanan Internet; jika tidak ada produk seperti itu di lini, maka firewall murni dipilih) dari berbagai produsen Versi produk terkini pada tanggal mulai pengujian (Mei 2013) dan dijalankan pada platform Windows 7 X32 :

1. Avast! Keamanan Internet (8.0.1488).
2. Keamanan Internet AVG (2013.0.3272).
3. Keamanan Internet Avira (13.0.0.3499).
4. Keamanan Internet Bitdefender (16.29.0.1830).
5. Keamanan Internet Comodo (6.1.276867.2813).
6. Ruang Keamanan Dr.Web (8.0).
7. Keamanan Cerdas Eset (6.0.316.0).
8. Keamanan Internet F-Secure (1.77 build 243).
9. Keamanan Internet G DATA (1.0.13113.239).
10. Firewall Pribadi Jetico (2.0).
11. Keamanan Internet Kaspersky (13.0.1.4190(g).
12. Keamanan Internet McAfee (11.6.507).
13. Keamanan Internet Kingsoft (2009.05.07.70).
14. Esensi Keamanan Microsoft (4.2.223.0) + Windows Firewall.
15. Keamanan Internet Norton (20.3.0.36).
16. Firewall Premium Armor Online (6.0.0.1736).
17. Suite Keamanan Pos Luar Pro (8.0 (4164.639.1856).
18. Keamanan Internet Panda (18/01/01).
19. Keamanan Internet Alat PC (9.1.0.2900).
20. Keamanan Internet Trend Micro Titanium (6.0.1215).
21. Keamanan Internet TrustPort (2013 (13.0.9.5102).

Sebelum memulai pengujian, lingkungan pengujian disiapkan. Untuk melakukan hal ini, sistem operasi Windows 7 Enterprise SP1 x86 dengan semua pembaruan yang tersedia saat itu, serta perangkat lunak tambahan yang diperlukan untuk pengujian, telah diinstal pada komputer yang bersih.

Pengujian dilakukan pada dua jenis pengaturan: standar yang direkomendasikan pabrikan (pengaturan default) dan maksimum. Dalam kasus pertama, pengaturan default yang direkomendasikan oleh pabrikan digunakan dan semua tindakan yang direkomendasikan oleh program dilakukan.

Selain itu, dalam kasus kedua, semua pengaturan yang dinonaktifkan dalam mode “default”, namun masih dapat mempengaruhi hasil pengujian, diaktifkan dan/atau dibawa ke posisi maksimum (pengaturan paling ketat). Dengan kata lain, menyetel pengaturan maksimum berarti mentransfer semua pengaturan yang tersedia dari antarmuka pengguna grafis semua modul yang terkait dengan pendeteksian file berbahaya atau aktivitas jaringan ke opsi yang paling ketat.

Pengujian firewall dilakukan dengan menggunakan kelompok serangan internal berikut, yang dibagi ke dalam tingkat kesulitan agar lebih jelas:

1. Tingkat kesulitan dasar (56 pilihan serangan):

1. memeriksa perlindungan proses dari penghentian (41 opsi serangan);
2. perlindungan terhadap serangan internal standar (15 opsi serangan).

2. Peningkatan tingkat kesulitan (8 pilihan serangan):

1. menguji perlindungan terhadap kebocoran non-standar (3 opsi serangan);
2. menguji perlindungan terhadap teknik non-standar untuk menembus mode kernel (5 opsi serangan).

Penjelasan rinci tentang semua metode serangan yang digunakan dalam pengujian dapat ditemukan di metodologi pengujian.

Memeriksa firewall untuk perlindungan terhadap serangan internal

Izinkan kami mengingatkan Anda bahwa menurut skema penghargaan yang digunakan, 1 poin (+) diberikan jika serangan diblokir secara otomatis dan fungsi perlindungan dari program yang diuji tidak rusak. 0,5 poin (atau +/-) - jika serangan diblokir hanya dalam keadaan khusus (misalnya, ketika pengguna memilih tindakan yang diinginkan dengan benar atas permintaan program yang sedang diuji). Dan terakhir, jika serangan berhasil seluruhnya atau sebagian dan menonaktifkan fungsi perlindungan, maka tidak ada poin yang diberikan. Jumlah poin maksimum yang mungkin diperoleh dalam tes ini adalah 64.

Tabel 1-2 dan Gambar 1-2 menunjukkan hasil pengujian firewall secara terpisah pada pengaturan standar dan maksimum. Untuk lebih jelasnya, hasil untuk setiap firewall dibagi menjadi dua kelompok: perlindungan terhadap serangan dengan tingkat kompleksitas dasar dan perlindungan terhadap serangan dengan tingkat kompleksitas yang meningkat.

Tabel 1: Hasil pengujian firewall untuk standarApengaturan rt

Produk yang Diuji							Total poin (maks. 64)	Total %
	Poin	%	% dari jumlah	Poin	%	% dari jumlah
Komodo	53	95%	82,8%	6	75%	9,4%	59	92%
Armor Daring	50	89%	78,1%	7,5	94%	11,7%	57,5	90%
Norton	45	80%	70,3%	6	75%	9,4%	51	80%
Jetico	46	82%	71,9%	4,5	56%	7,0%	50,5	79%
Pos terdepan	45	80%	70,3%	2,5	31%	3,9%	47,5	74%
Tren Mikro	42	75%	65,6%	3	38%	4,7%	45	70%
Kaspersky	42	75%	65,6%	2,5	31%	3,9%	44,5	70%
Dr.Web	42,5	76%	66,4%	2	25%	3,1%	44,5	70%
Pelabuhan Kepercayaan	43	77%	67,2%	0,5	6%	0,8%	43,5	68%
G DATA	42	75%	65,6%	1	13%	1,6%	43	67%
Avast	41	73%	64,1%	1	13%	1,6%	42	66%
eset	41	73%	64,1%	1	13%	1,6%	42	66%
Pembela Bit	41	73%	64,1%	1	13%	1,6%	42	66%
Rata-rata	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
Alat PC	41	73%	64,1%	0	0%	0,0%	41	64%
Avira	40	71%	62,5%	0	0%	0,0%	40	63%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Aman	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Gambar 1: Hasil pengujian firewall pada pengaturan standar

Perlindungan terhadap serangan internal pada pengaturan yang direkomendasikan oleh pabrikan masih menyisakan banyak hal yang diinginkan. Hanya tiga firewall yang mampu mengatasi ambang batas 80% pada pengaturan standar - Comodo, Online Armor, dan Norton. Produk Jetico (79%) dan Outpost (74%) cukup dekat dengan mereka. Hasil dari firewall lain jauh lebih buruk.

Dibandingkan dengan hasil tes terakhir, semua pemimpin mengkonfirmasi hasil tinggi mereka; hanya ada pergerakan kecil dalam kelompok terdepan, misalnya Outpost dan Jetico bertukar posisi. Satu-satunya kejutan adalah produk Norton, yang pada pengujian sebelumnya menunjukkan hasil 45% dan berada di posisi terbawah, dan pada pengujian ini dengan 80% menempati posisi ketiga.

Hasil yang diperoleh disebabkan oleh fakta bahwa banyak produsen menetapkan pengaturan standar sedemikian rupa untuk mengurangi jumlah pesan yang harus ditanggapi oleh pengguna. Hal ini dikonfirmasi oleh hasil pengujian - pada pengaturan standar, firewall mengajukan pertanyaan kepada pengguna hanya pada 5,4% serangan, dan pada pengaturan maksimum - pada 9,2% serangan. Namun, hal ini mempengaruhi kualitas perlindungan, yang akan tetap diam dalam situasi di mana program jahat meniru/melakukan tindakan yang sepenuhnya sah dalam sistem.

Anda juga harus memperhatikan dua pola. Pertama, persentase pencegahan jenis serangan kompleks secara umum jauh lebih buruk dibandingkan serangan tingkat kompleksitas dasar. Lebih dari separuh serangan ini hanya ditolak oleh empat produk - Comodo, Online Armor, Norton, dan Jetico. Empat produk lainnya termasuk dalam kelompok perbatasan, yang menolak 25% hingga 38% serangan tersebut: Outpost, Trend Micro, Kaspersky, dan Dr.Web. Semua produk lainnya menolak tidak lebih dari satu serangan kompleks. Kedua, performa dalam menangkis serangan dasar telah meningkat. Jika pada pengujian sebelumnya 11 (50%) produk menolak kurang dari 50% serangan, maka pada pengujian ini hanya ada 3 (14%) produk yang menolak.

Tabel 2: Hasil pengujian firewall pada pengaturan maksimal

Produk yang Diuji	Serangan tingkat kesulitan dasar (maks. 56 poin)			Serangan dengan tingkat kesulitan yang lebih tinggi (maks. 8 poin)			Total poin (maks. 64)	Total %
	Poin	%	% dari jumlah	Poin	%	% dari jumlah
Komodo	56	100%	87,5%	8	100%	12,5%	64	100%
Pembela Bit	56	100%	87,5%	8	100%	12,5%	64	100%
Armor Daring	53	95%	82,8%	8	100%	12,5%	61	95%
Kaspersky	53	95%	82,8%	7	88%	10,9%	60	94%
Norton	50,5	90%	78,9%	8	100%	12,5%	58,5	91%
Alat PC	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Pos terdepan	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
eset	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
Dr.Web	46,5	83%	72,7%	5	63%	7,8%	51,5	80%
Jetico	46	82%	71,9%	4,5	56%	7,0%	50,5	79%
Tren Mikro	43	77%	67,2%	3	38%	4,7%	46	72%
Pelabuhan Kepercayaan	43	77%	67,2%	2,5	31%	3,9%	45,5	71%
G DATA	42	75%	65,6%	3	38%	4,7%	45	70%
Avira	41,5	74%	64,8%	2	25%	3,1%	43,5	68%
Avast	41	73%	64,1%	1,5	19%	2,3%	42,5	66%
Rata-rata	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Aman	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Gambar 2: Hasil pengujian firewall pada pengaturan maksimal

Ketika pengaturan maksimum diaktifkan, kualitas perlindungan terhadap serangan internal di banyak firewall yang diuji meningkat secara signifikan. Hal ini terutama terlihat di kalangan petani menengah yang kuat. Semua pemimpin tes sebelumnya juga menunjukkan hasil yang tinggi dalam tes ini. Di antara perubahan tersebut, perlu diperhatikan produk Bitdefender, yang, bersama dengan Comodo, menunjukkan hasil 100%, dan produk Norton, yang pindah ke grup terdepan.

Hasil beberapa produk pada setting standar dan maksimal sama. Hal ini disebabkan karena produk tersebut tidak memiliki pengaturan yang dapat mempengaruhi hasil pengujian kami.

Perbandingan kualitas proteksi pada pengaturan standar dan maksimal

Karena logika pengujian ini, kami tidak akan menjumlahkan atau merata-ratakan hasil produk yang sama dengan pengaturan berbeda. Sebaliknya, kami ingin membandingkannya dan menunjukkan perbedaan yang signifikan dalam kualitas perlindungan produk yang diuji bergantung pada pengaturan yang digunakan.

Agar lebih jelas, hasil akhir pengujian firewall dengan setting standar dan maksimal kami sajikan pada Tabel 3 dan Gambar 3.

Tabel 3: Ringkasan hasil pengujian firewall pada pengaturan standar dan maksimum

Produk	Pengaturan standar	Pengaturan maksimal
Komodo	92%	100%
Armor Daring	90%	95%
Norton	80%	91%
Jetico	79%	79%
Pos terdepan	74%	85%
Tren Mikro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
Pelabuhan Kepercayaan	68%	71%
G DATA	67%	70%
Avast	66%	66%
eset	66%	85%
Pembela Bit	66%	100%
Rata-rata	64%	64%
McAfee	64%	64%
Alat PC	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Aman	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Gambar 3: Ringkasan hasil pengujian firewall pada pengaturan standar dan maksimum

Gambar 3 dengan jelas menunjukkan perbedaan hasil pengujian tergantung pada pengaturan yang dipilih.

Pertama, hanya dua produk – Comodo dan Online Armor – yang menunjukkan indikator perlindungan mendekati maksimum, baik pada pengaturan standar maupun maksimum.

Kedua, ketika pengaturan standar yang diusulkan oleh pabrikan diubah, beberapa produk menunjukkan tingkat perlindungan yang jauh lebih baik. Hal ini paling jelas terlihat pada produk seperti Bitdefender, Kaspersky, Eset, F-Secure dan PC Tools.

Ketiga, seperti disebutkan di atas, beberapa produk yang diuji tidak memiliki pengaturan sama sekali yang dapat mempengaruhi hasil pengujian. Oleh karena itu, hasilnya untuk semua jenis pengaturan dalam pengujian ini adalah sama. Grup ini mencakup Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft dan Microsoft.

Skor akhir tidak memperhitungkan situasi di mana serangan berhasil dihalau, namun terdapat masalah dengan antarmuka pengguna produk. Dalam kebanyakan kasus, masalahnya terdiri dari antarmuka yang mogok dalam waktu singkat (dari 2 hingga 10 detik) atau hingga booting sistem operasi berikutnya. Meskipun produk terus memberikan perlindungan terhadap masalah antarmuka pengguna, keberadaan masalah tersebut secara subjektif dianggap negatif dan dapat memengaruhi preferensi pemilihan produk. Jumlah masalah pada antarmuka pengguna disajikan pada Tabel 3 dan Gambar 3. Kesalahan yang timbul dari serangan level 1 dinilai, dengan jumlah total 41.

Tabel 4: Jumlah masalah antarmuka pengguna pada pengaturan standar dan maksimum

Produk yang Diuji	Pengaturan standar		Pengaturan maksimal
	Jumlah kesalahan	%	Jumlah kesalahan	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	20	49%	20	49%
F-Aman	19	46%	19	46%
Panda	17	41%	17	41%
Jetico	16	39%	16	39%
Alat PC	13	32%	13	32%
Tren Mikro	12	29%	12	29%
Rata-rata	10	24%	9	22%
Pelabuhan Kepercayaan	9	22%	9	22%
G DATA	9	22%	9	22%
Pembela Bit	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Pos terdepan	5	12%	5	12%
eset	5	12%	4	10%
Komodo	5	12%	0	0%
Avira	2	5%	2	5%
Dr.Web	2	5%	2	5%
Kaspersky	1	2%	1	2%
Armor Daring	1	2%	1	2%

Gambar 4: Jumlah masalah UI pada pengaturan standar dan maksimum

Hasilnya menunjukkan bahwa produk McAfee dan Microsoft mengalami masalah antarmuka pengguna pada sebagian besar serangan (lebih dari 80%). Ini bisa disebut tingkat yang tidak dapat diterima, karena... Hampir semua serangan yang berhasil dihalau akan menimbulkan masalah. Hasil yang cukup buruk, berkisar antara 30% hingga 50%, ditunjukkan oleh produk dari Kingsoft, F-Secure, Panda, Jetico dan PC Tools. Saat menggunakannya, setiap 2-3 serangan akan menyebabkan masalah pada antarmuka. Sejumlah produk lain menunjukkan hasil 10% hingga 30% yang bisa dikatakan memuaskan. Produk Avira, Dr.Web, Kaspersky dan Online Armor menunjukkan hasil yang baik, dengan masalah yang terjadi pada kisaran 2% hingga 5% serangan. Satu-satunya produk yang tidak pernah mengalami masalah antarmuka pengguna adalah Comodo pada pengaturan maksimum, yang dapat dianggap sebagai hasil yang sangat baik. Namun, dengan pengaturan standar, hasil Comodo menurun (12%), yang menunjukkan bahwa penggunaan produk ini memerlukan pengetahuan tentang cara mengkonfigurasinya.

Hasil tes akhir dan penghargaan

Sama seperti pengujian sebelumnya, kami tidak menghitung rata-rata hasil produk yang sama dengan pengaturan berbeda, tetapi mempertimbangkannya secara independen satu sama lain. Dengan demikian, setiap produk yang diuji dapat menerima dua penghargaan, satu untuk setiap jenis setting.

Sesuai dengan skema penghargaan, firewall terbaik menerima penghargaan yang menunjukkan pengaturan yang digunakan, lihat Tabel 4.

Tabel 5: Hasil akhir pengujian firewall pada pengaturan standar dan maksimum

Produk sedang diuji	Pilihan pengaturan	Pencegahan Serangan [%]		Total [%]	Hadiah
		Basis tingkat kesulitan	Peningkatan tingkat kesulitan
Komodo	Maks	100%	100%	100%	Platinum Firewall Keluar Penghargaan Perlindungan
Pembela Bit	Maks	100%	100%	100%
Armor Daring	Maks	95%	100%	95%	Keluar Firewall Emas Penghargaan Perlindungan
Kaspersky	Maks	95%	88%	94%
Komodo	Standar	95%	75%	92%
Norton	Maks	90%	100%	91%
Armor Daring	Standar	89%	94%	90%
Alat PC	Maks	88%	69%	86%
Pos terdepan	Maks	88%	69%	85%
eset	Maks	88%	69%	85%
Norton	Standar	80%	75%	80%
Dr.Web	Maks	83%	63%	80%
Jetico	Maks	82%	56%	79%	Keluar Firewall Perak Penghargaan Perlindungan
Jetico	Standar	82%	56%	79%
Pos terdepan	Standar	80%	31%	74%
Tren Mikro	Maks	77%	38%	72%
Pelabuhan Kepercayaan	Maks	77%	31%	71%
Tren Mikro	Standar	75%	38%	70%
Kaspersky	Standar	75%	31%	70%
Dr.Web	Standar	76%	25%	70%
G DATA	Maks	75%	38%	70%
Pelabuhan Kepercayaan	Standar	77%	6%	68%	Keluar Firewall Perunggu Penghargaan Perlindungan
Avira	Maks	74%	25%	68%
G DATA	Standar	75%	13%	67%
Avast	Maks	73%	19%	66%
Avast	Standar	73%	13%	66%
eset	Standar	73%	13%	66%
Pembela Bit	Standar	73%	13%	66%
Rata-rata	Maks	73%	0%	64%
Rata-rata	Standar	73%	0%	64%
McAfee	Maks	73%	0%	64%
McAfee	Standar	73%	0%	64%
Alat PC	Standar	73%	0%	64%
Microsoft	Maks	71%	0%	63%
Microsoft	Standar	71%	0%	63%
Avira	Standar	71%	0%	63%
F-Aman	Maks	56%	13%	51%	Tidak ada imbalan
F-Aman	Standar	56%	13%	51%
Panda	Maks	54%	0%	47%
Panda	Standar	54%	0%	47%
Kingsoft	Maks	48%	13%	44%
Kingsoft	Standar	48%	13%	44%

Hasil terbaik dalam pengujian ini ditunjukkan oleh firewall Comodo dan Bitdefender, yang memperoleh skor 100% pada pengaturan maksimum. Kedua produk ini memenangkan penghargaan Platinumtembok apiKeluarPerlindunganMenghadiahkan.

Hasil pengujian yang sangat tinggi (lebih dari 80%) juga ditunjukkan oleh firewall Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset dan Dr.Web, yang menerima penghargaan Emastembok apiKeluarPerlindunganMenghadiahkan. Penting untuk dicatat bahwa Comodo menerima penghargaan ini pada pengaturan standar, Online Armor dan Norton pada pengaturan standar dan maksimum, dan yang lainnya hanya pada pengaturan maksimum.

Berikutnya dalam daftar adalah sekelompok tujuh firewall yang hasilnya berada pada kisaran 60% hingga 70%. Ini adalah Outpost, Kaspersky dan Dr.Web dengan pengaturan standar; TrustPort dan G DATA pada pengaturan maksimum, serta Jetico dan Trend Micro pada pengaturan standar dan maksimum. Mereka semua mendapat hadiah

Sekelompok produk yang cukup besar yang berada dalam kisaran 60% hingga 70% menerima penghargaan. Perlu dicatat bahwa produk Eset dan Bitdefender pada pengaturan standar mampu menangkis lebih banyak serangan pada pengaturan maksimum.

Anda dapat melihat detail hasil tes dan memastikan perhitungan akhir sudah benar dengan mengunduh hasil tes dalam format Microsoft Excel.

Shabanov Ilya, mitra pengelola situs:

“Saya sangat senang dengan kenyataan bahwa banyak produsen telah meningkatkan secara signifikan perlindungan proaktif terhadap serangan internal dan pertahanan diri pada produk mereka. Kami bahkan harus merevisi skema penghargaan untuk meningkatkan standar persyaratan. Skor kurang dari 51% kini dianggap gagal total.

Saya sangat terkejut bahwa Bitdefender menangkis 100% serangan dalam mode paranoid, Eset dan Dr.Web dengan hasil pada pengaturan maksimum masing-masing 85% hingga 80%, serta pendatang baru dalam pengujian kami, TrustPort. Berdasarkan hasil pengujian ini, produk “kelompok emas” mencakup firewall dari Comodo, Norton, dan Online Armor, yang memperoleh skor lebih dari 80% pada pengaturan standar dan maksimum. Hasil tinggi secara konsisten dalam pengujian yang melibatkan perlindungan proaktif ditunjukkan oleh Kaspersky, Outpost, dan PC Tools.

Namun, dalam kasus sejumlah produk yang diuji, logika penetapan pengaturan standar tidak jelas. Akibatnya, tingkat perlindungan bagi sebagian besar pengguna yang terbiasa menggunakan perlindungan dengan pengaturan standar menjadi jauh lebih rendah. Hal ini terutama berlaku untuk produk dari Bitdefender, Kaspersky, Eset, dan PC Tools.”

Mikhail Kartavenko, kepala situs web laboratorium pengujian:

“Mengingat pengujian ini sebagai kelanjutan dari pengujian serupa sebelumnya, kami dapat mengidentifikasi beberapa tren dan masalah utama dalam pengoperasian firewall.

Pertama, rata-rata, sebagian besar produk menunjukkan hasil yang lebih baik dibandingkan 1,5 tahun yang lalu, namun mereka melakukannya terutama dengan menangkis serangan level 1 yang paling sederhana. Serangan yang lebih kompleks hanya akan sulit dilakukan pada produk tertentu.

Kedua, meskipun perlindungan proses terhadap penghentian (tingkat serangan pertama) berhasil, antarmuka pengguna banyak produk mengalami crash. Hal ini menempatkan pengguna pada posisi yang canggung di mana dia tidak mengerti apakah perlindungannya berfungsi atau tidak.

Ketiga, terdapat kesenjangan yang cukup besar dalam kinerja firewall pada pengaturan standar dan maksimum. Akibatnya, tingkat perlindungan yang dapat diterima seringkali hanya dapat diperoleh oleh pengguna berpengalaman yang mengetahui dan dapat mengkonfigurasi firewall dengan benar.

Oleh karena itu, pengujian ini mengidentifikasi kelemahan firewall modern, yang solusinya dapat meningkatkan perlindungannya.”

Bagian ini diperbarui setiap hari. Selalu versi terbaru dari program gratis terbaik untuk penggunaan sehari-hari di bagian Program yang Diperlukan. Hampir semua yang Anda perlukan untuk pekerjaan sehari-hari tersedia. Mulailah secara bertahap meninggalkan versi bajakan demi versi gratis yang lebih nyaman dan fungsional. Jika Anda masih belum menggunakan obrolan kami, kami sangat menyarankan Anda untuk membacanya. Di sana Anda akan menemukan banyak teman baru. Selain itu, ini adalah cara tercepat dan efektif untuk menghubungi administrator proyek. Bagian Pembaruan Antivirus terus berfungsi - pembaruan gratis selalu terkini untuk Dr Web dan NOD. Tidak punya waktu untuk membaca sesuatu? Isi ticker selengkapnya dapat ditemukan di tautan ini.

Firewall gratis Comodo. Pengujian, kesimpulan

Comodo Firewall sedang beraksi

Setelah instalasi dan konfigurasi, Comodo bersembunyi di baki dan mulai mengganggu saya dengan pertanyaan-pertanyaannya. Pada hari pertama saya bermain-main dengan semua firewall dan mode perlindungan proaktif dan akhirnya membungkamnya. Tidak ada rem yang ditemukan di sistem kami setelah kemunculannya. Secara umum, bekerja dengan firewall dari Comodo cukup mudah dan nyaman. Antarmuka jendela utama sangat sederhana dan informatif:

Namun saya harus membiasakan diri menavigasi firewall dan pengaturan perlindungan proaktif - tidak selalu mungkin menemukan item yang tepat dengan cepat. Saya pikir ini akan hilang seiring berjalannya waktu.

Beberapa hari setelah menginstal Comodo Firewall, saya memutuskan untuk mengujinya sedikit.

Tes No.1. Pengujian daring

Ketika Anda mengklik tombol "Uji", program mencoba membuat koneksi dengan server situs.

Karena Comodo Firewall belum mengetahui utilitas ini, pertama kali mencoba mengakses Internet, ada reaksi langsung dari perlindungan proaktif dan firewall:

Dalam kedua kasus tersebut, saya mengklik blokir dan menerima konfirmasi bahwa pengujian berhasil:

Lalu saya mengganti nama file tersebut FireWallTest.exe V opera.exe dan mengganti file Opera standar dengan itu. Oleh karena itu, saya mencoba mengelabui Comodo Firewall yang sudah mengetahui browser ini dengan baik dan terus-menerus serta secara otomatis merilisnya ke Internet. Comodo bereaksi terhadap peluncuran Opera “palsu” dari Total sebagai berikut:

Setelah menerima izin saya untuk peluncuran satu kali, firewall memperingatkan saya bahwa Opera sedang mencoba mengakses Internet:

Ternyata aplikasi apa pun yang sudah ada aturannya, jika file executable diganti tanpa sepengetahuan saya, tidak akan bisa akses Internet. Segalanya tampak baik-baik saja, tetapi ada satu hal: warna bagian atas jendela peringatan bergantung pada tingkat keparahan situasi. Jika Comodo menilai suatu peristiwa sebagai peristiwa kritis, warnanya akan menjadi merah, jika peristiwa tersebut kurang berbahaya, maka akan menjadi kuning. Dalam kasus saya, Comodo menganggap situasi simulasi tidak terlalu berbahaya dan menyalakan lampu “kuning”. Selain itu, alih-alih menggunakan kata “file yang dapat dieksekusi opera.exe tidak dikenali" Saya lebih suka melihat bahwa "ada perubahan pada parameter file opera.exe" Beginilah cara pemanen dari Kaspersky dan Eset, misalnya, memperingatkan dalam situasi seperti itu. Selain itu, pengguna melihat jendela alarm menggunakan warna merah, yang langsung memaksa mereka untuk memperhatikan situasi. Dan peringatan dari Comodo dapat diabaikan begitu saja oleh pengguna karena kurangnya penekanan pada peristiwa yang terjadi.

Mengganti file Opera hanyalah bagian dari rencana jahat saya. Korban berikutnya adalah Internet Explorer 6, yang terintegrasi ke dalam sistem operasi, dan, oleh karena itu, iexplore.exe dapat dianggap sebagai file sistem lengkap. Bayangkan betapa terkejutnya saya ketika, di tengah keheningan Comodo, saya melihat jendela tentang kegagalan pengujian:

Rupanya, aturan tambahan telah dibuat, saya memutuskan dan masuk ke firewall dan kebijakan perlindungan proaktif. Setelah mencari-cari di sana selama sekitar 15 menit, saya membuat satu-satunya keputusan yang tepat - menginstal ulang Comodo. Tidak lama setelah diucapkan, dilakukan. Membiarkan mode operasi default, saya mengulangi percobaan dengan substitusi iexplore.exe. Saat diluncurkan dari Total, perlindungan proaktif berfungsi, seperti halnya Opera:

Di sini kita harus membuat penyimpangan liris kecil. Faktanya adalah ketika file executable IE diganti, sistem mengembalikan yang asli dalam waktu 4-8 detik iexplore.exe. Dalam hal ini, hasil pengujian saya bergantung pada apakah file palsu berhasil menjangkau Internet atau tidak.

Jika saya berhasil menyelesaikan semua manipulasi sebelum memulihkan explore.exe, hal berikut akan terjadi. Setelah menerima izin saya untuk peluncuran satu kali jelajahi.exe, Total meluncurkan utilitas FireWallTest, tekan "Test", perlindungan proaktif Defens+ mengeluarkan peringatan:

Jika kami mengizinkannya (sebagai percobaan), firewall akan berfungsi:

Kami berhasil mengklik "Blokir" - tes lulus, utilitas tidak terhubung ke Internet. Tapi jika iexplore.exe dipulihkan sebelum Anda menekan tombol blokir - tidak ada yang bergantung pada pilihan Anda - utilitas secara otomatis mendapatkan akses Internet pada saat file asli dipulihkan.

Hal yang sama berlaku untuk pekerjaan perlindungan proaktif: jika Anda tidak punya waktu untuk memerintahkan pemblokiran sebelum pemulihan jelajahi.exe- utilitas secara otomatis mendapatkan akses ke Internet.

Setelah cukup bermain-main dengan IE palsu, saya teringat kegagalan tes pertama, ketika Comodo tetap diam dan merilis file yang "salah" di Internet. Setelah menginstal ulang Comodo, saya memasukkan Defense+ dan firewall ke mode pelatihan dan meluncurkan IE. Setelah itu, saya mengembalikan mode default dan mengulangi pengujian. Comodo diam-diam gagal lagi...

Tes No.3. Duel

Terkesan dengan hasil pengujian sebelumnya, saya mencari peluang tambahan untuk menguji Comodo dan akhirnya menemukan utilitas AWFT.

Program ini mengemulasi perilaku Trojan dan berisi serangkaian enam pengujian yang menunjukkan berbagai metode akses tidak sah ke jaringan, melewati perlindungan firewall. Di antara pengujian ini terdapat cara lama untuk menipu firewall dan teknik yang lebih modern. Untuk setiap tes yang berhasil dilewati, firewall diberikan sejumlah poin tertentu. Jika tes tidak lulus, poin akan diberikan kepada AWFT. Jumlah poin maksimum adalah sepuluh.

Utilitasnya adalah shareware, terbatas pada 10 peluncuran. Di bagian atas jendela program terdapat tombol yang meluncurkan pengujian terkait; di bagian bawah adalah situs tempat AWFT akan menerobos, dan hasil duel antara firewall dan utilitas. Tombol Reset Poin digunakan untuk mengatur ulang akumulasi poin.

Untuk berjaga-jaga, saya memutuskan untuk mengubah alamat situs menjadi milik saya sendiri.

Pengujian dilakukan dengan Comodo Firewall dan Defense+ dihidupkan, Opera berjalan, dan monitor Avira dimatikan.

Pengujian pertama menggunakan teknik memuat salinan tersembunyi dari browser dan menambal memori sebelum meluncurkannya.

Ketika saya mengklik tombol tes, sebuah jendela muncul dengan kesalahan:

Setelah menutup jendela ini, Comodo merespons pengujian dengan jendela permintaan; ketika Anda mengklik tombol "Blokir", AWFT, setelah berpikir sejenak, memberikan poin pertama ke firewall.

Menurut pengembang utilitas, tes No. 2 adalah trik lama dan terkenal. Comodo merespons lagi dengan jendela permintaan dan kembali mencetak poin.

Tes #3 juga menggunakan trik lama. Comodo diam-diam memblokirnya, rupanya triknya sudah sangat terkenal.

Tes No. 4 mirip dengan tes pertama dengan meluncurkan salinan tersembunyi dari browser dan menambal memori sebelum meluncurkannya. Firewall tidak memberikan peringatan apa pun, tetapi setelah jeda singkat, firewall tersebut mendapatkan poin lain.

Selama pengujian kelima dan keenam, Anda perlu beralih ke browser dan berselancar sedikit (saya baru saja menyegarkan halaman yang dimuat di browser).

Dalam pengujian No. 5, utilitas melakukan pencarian heuristik untuk perangkat lunak resmi yang diinstal pada komputer (atau jaringan) yang memiliki akses ke Internet melalui port 80, kemudian meluncurkan salinan program resmi dan, sebelum peluncuran, menambal memori ditempati oleh program ini (yaitu, AWFT diluncurkan sendiri di memori program yang diizinkan). Comodo diam-diam menyelesaikan tes tersebut dan menerima 3 poin untuk itu.

Tes No. 6 serupa dengan tes kelima sebelumnya. Teknik yang sama digunakan dengan pencarian heuristik untuk perangkat lunak yang diinstal yang memiliki hak untuk keluar melalui port 80. Hanya metode peretasan yang kini diubah - permintaan pengguna digunakan. Pada saat yang sama, AWFT mencoba memasang toolbar kiri yang tersembunyi ke browser. Ketika saya membuka Opera, jendela berikut muncul:

Saat saya mengkonfirmasi permintaan pengguna ini, Comodo mengeluarkan permintaannya, utilitas diblokir lagi, dan firewall menerima kredit 3 poin.

Hasil duel tersebut adalah 10:0 untuk keunggulan Comodo. Mengulangi tes dengan Internet Explorer terbuka, saya mendapatkan hasil yang sama.

Kesimpulan

Meskipun masih ada rasa tidak enak di jiwa saya setelah menguji firewall, saya tetap merekomendasikan Comodo Internet Security untuk digunakan di rumah, tetapi hanya sebagai firewall. Dan jangan dengarkan orang-orang pintar yang menyarankan untuk menonaktifkan perlindungan proaktif, dalam kondisi apa pun! Hanya dengan penggunaan Defense+ firewall ini benar-benar menjamin keamanan komputer Anda. Namun yang sebaiknya tidak Anda gunakan adalah antivirus Comodo. Tidak hanya melewatkannya sedikit, tetapi Anda akan mengalami masalah dalam memperbaruinya - basis datanya sangat rumit. Selain itu, hal ini berdampak signifikan terhadap kinerja sistem. Comodo Firewall dan Avira Antivir Personal bekerja dengan baik untuk saya.

Saya tidak menemukan rem atau gangguan apa pun pada sistem saat firewall sedang berjalan. Saya akan menyimpan pemikiran saya tentang hasil pengujian saya untuk saat ini; saya ingin mendengar komentar Anda.

Saat menulis bagian akhir artikel ini, saya menemukan hasil pengujian firewall terbaru yang dilakukan oleh laboratorium Matousec. Comodo Internet Security adalah satu-satunya firewall dengan skor 100% (lihat forum firewall). Baiklah, aku sudah menentukan pilihanku... Dan kamu?

kelebihan (jelas):
distribusi gratis,
ketersediaan database program sendiri;
ketersediaan perlindungan proaktif (Defense+);
kemudahan instalasi dan pengaturan awal;
jendela yang sangat informatif dan nyaman dengan ringkasan;

pro (meragukan):
kehadiran beberapa mode operasi;

kontra (jelas):
mode instalasi yang mengganggu;
penggantian file yang dapat dieksekusi tidak diidentifikasi oleh perlindungan proaktif sebagai peristiwa kritis;

kontra (diragukan):
antivirus yang sejujurnya tidak berhasil.

Pengujian Firewall adalah satu-satunya cara untuk memastikan secara akurat apakah firewall benar-benar berfungsi seperti yang diharapkan. Aturan firewall yang rumit, antarmuka manajemen yang buruk, dan faktor lainnya sering kali menyulitkan penentuan status firewall. Dengan menggunakan dimungkinkan untuk menentukan status firewall secara akurat.

Jenis pengujian firewall ini mencoba membuat koneksi ke layanan yang menghadap ke luar dari perspektif yang sama sebagai penyerang. Layanan terbuka yang tidak terlindungi (port mendengarkan) dapat menjadi kelemahan keamanan utama dalam konfigurasi firewall atau router yang buruk.

Masukkan alamat IP dalam formulir di bawah ini untuk melakukan a tes firewall online cepat. Pemindaian port akan dilakukan uji 10 yang paling umum Layanan TCP (port), dengan hasil yang menunjukkan port terbuka, tertutup, atau terfilter.

Mulai Tes Firewall

Tes firewall ini adalah gambaran umum tingkat tinggi yang dapat mengungkapkan status firewall sistem berdasarkan respons port. Lihat Tutorial Nmap untuk detail lebih lanjut tentang interpretasi hasil.

Pastikan cakupan lengkap saat menguji firewall dengan memindai semua port 65535. Jalankan perangkat lunak sendiri atau cukup lakukan uji firewall komprehensif menggunakan host kami Pemindai Port Nmap Online.

Mengapa Anda Membutuhkan Tes Firewall Eksternal

Untuk memahami seberapa rentan sistem Anda terhadap penyerang eksternal, Anda perlu memahami seperti apa mereka di jaringan dari perspektif eksternal atau perspektif Internet. Pemindaian port yang dilakukan dari luar perimeter jaringan akan memetakan dan mengidentifikasi sistem yang rentan.

Staf operasi teknis perlu mengetahui seperti apa perimeter jaringan mereka dari luar. Perimeternya dapat berupa gateway IP tunggal, server Internet yang dihosting, atau seluruh jaringan Kelas B; tidak masalah - Anda perlu memahami layanan apa yang dapat dilihat oleh ancaman berbasis Internet dan apa yang dapat mereka akses.

Jika Anda seorang administrator sistem atau analis keamanan untuk suatu organisasi, memiliki akses ke pemindai port eksternal akan memberikan sejumlah manfaat. Yang paling penting adalah Anda harus melakukannya mengetahui layanan yang mendengarkan di perimeter Anda. Pengujian harus dilakukan setidaknya setiap bulan dan idealnya lebih sering, untuk memantau perubahan pada perimeter.

Firewall Router Rumah

Bagi banyak pengguna, router rumah adalah perangkat firewall yang harus mereka kelola. Dalam hal ini konfigurasi yang paling umum adalah perangkat SOHO menjalankan NAT (terjemahan alamat jaringan). Dalam konfigurasi NAT, jaringan internal memiliki sejumlah perangkat pada rentang alamat IP pribadi (192.168.1.x) dan mereka berkomunikasi dengan Internet melalui router SOHO. Router memiliki satu alamat IP publik yang ditetapkan oleh penyedia Internet atau ISP. Penerjemahan alamat IP internal ke publik adalah proses NAT.

Router rumah harus dipindai portnya untuk memeriksa dua pertimbangan penting:

1. Perangkat itu sendiri mungkin memiliki layanan mendengarkan untuk manajemen seperti HTTP (tcp port 80) atau Telnet (tcp port 23). Ini biasanya hanya dapat diakses dari jaringan Internal, tetapi jika mereka mendengarkan di sisi Internet Publik maka siapa pun dapat mengaksesnya dan jika kata sandinya default atau lemah maka ini dapat diakses dengan mudah. Jika seseorang memiliki akses ke router Anda, mereka dapat menyerang perangkat apa pun di jaringan internal.

2. Port Forwarding adalah pertimbangan penting lainnya, dimana antarmuka eksternal meneruskan lalu lintas ke alamat internal sehingga dapat diakses dari Internet. Jika Anda menghosting layanan di jaringan internal dan ingin layanan ini dapat diakses, Anda dapat menyiapkan aturan penerusan porta pada router SOHO. Pemindaian port pada alamat IP eksternal dapat membantu memecahkan masalah penerusan port dan memastikan bahwa tidak ada layanan yang diteruskan yang tidak seharusnya.

Administrasi Firewall

Identifikasi lebih lanjut terhadap sistem operasi sebenarnya juga dimungkinkan, baik dari identifikasi layanan atau melalui analisis tingkat rendah terhadap paket-paket yang kembali dari host.

Administrator sistem dan jaringan juga akan menggunakannya untuk memetakan jaringan eksternal suatu host atau organisasi. Jaringan berubah seiring waktu dan dokumentasi tidak selalu terkini, sehingga pemindaian port cepat dari layanan yang mendengarkan di jaringan akan membantu administrator sistem untuk memahami tata letak jaringan.