Komputer riba sangat popular sebagai komputer rumah hari ini kerana ia mengambil sedikit ruang dan boleh dipindahkan dengan mudah dari bilik ke bilik. Ramai pengguna di rumah mendayakan perkongsian fail untuk, contohnya, memainkan kandungan digital pada sistem multimedia dan televisyen mereka.

Kebanyakan pengguna ini membawa komputer riba mereka ke tempat awam, seperti kafe, dan menyambung ke Internet menggunakan rangkaian Wi-Fi wayarles. Adalah munasabah untuk menjangkakan bahawa apabila anda meminta tembok api dan memilih rangkaian sebagai awam, komputer harus dilindungi daripada pencerobohan daripada peserta lain dalam rangkaian terbuka.

Pengguna perniagaan yang menggunakan komputer riba sebagai satu-satunya komputer kerja mereka mungkin mendapati diri mereka berada dalam situasi yang sama, dengan mesin mereka paling kerap dikonfigurasikan untuk dikawal melalui Desktop Jauh Microsoft.

Tujuan ujian ini adalah untuk menentukan cara tembok api pihak ketiga yang paling popular—berdiri sendiri dan sebagai sebahagian daripada suite Keselamatan Internet—sebenarnya menyediakan kawalan akses masuk asas untuk pengguna komputer riba yang bertukar antara rangkaian rumah/kerja dan awam.

Sila ambil perhatian bahawa skop ujian jelas sangat terhad, dan oleh itu keputusan yang baik dalam ujian ini tidak bermakna produk itu menyediakan keselamatan rangkaian yang lengkap.

Ujian telah dijalankan pada Januari 2014 atas perintah majalah CHIP Online (Jerman). Versi firewall yang digunakan tersedia pada 13 Januari 2014.

Prosedur ujian firewall

PC ujian disambungkan ke Internet melalui wayarles rangkaian tempatan(WLAN) menggunakan sambungan rangkaian yang ditakrifkan sebagai Peribadi dalam Windows Network and Sharing Center (WNSC).

Versi ujian bagi setiap produk yang tersedia mulai 13 Januari 2014 dipasang dengan tetapan lalai dan komputer ujian dibut semula. Jika produk itu sendiri menggesa pengguna untuk menentukan jenis rangkaian semasa sebagai Persendirian/Dipercayai, pilihan ini akan dipilih. Jika produk mempunyai fungsi kemas kini, maka ia dilakukan. Mengesahkan bahawa produk berdaftar dengan Pusat Sokongan Windows sebagai tembok api sistem, dan produk itu sendiri menunjukkan bahawa ia berfungsi seperti yang diharapkan. Gunakan PC kedua untuk menguji ketersambungan pada rangkaian peribadi sedia ada dengan cara berikut:

• Ping nama hos -4
• Ping nama hos -6
• Ping alamat IPv4
• Ping alamat IPv6
• Nama hos perkongsian fail
• Perkongsian fail alamat IPv4
• Nama hos Desktop Jauh (RDP).
• Alamat IPv4 Desktop Jauh (RDP).
• Alamat IPv6 Desktop Jauh (RDP).

Semua bentuk capaian jauh ini disahkan berfungsi untuk memastikan kefungsian penuh PC ujian pada rangkaian persendirian dan kawalan maksimum ke atasnya. Selepas ini, komputer dan penghala yang disambungkan dimatikan, dan PC bermula semula. Ia kemudian bersambung ke WLAN lain, yang ditakrifkan sebagai Awam dalam WNSC, menggunakan kotak dialog Windows Firewall.

Jika tembok api menunjukkan permintaannya untuk menentukan jenis rangkaian, ia ditetapkan kepada "Awam" atau "Tidak Dipercayai". Tiada perubahan lanjut dibuat pada persediaan produk.

Prosedur ini memodelkan gelagat biasa pengguna komputer riba yang berpindah dari rumah/pejabat ke rangkaian awam di kedai kopi, lapangan terbang atau hotel. Selepas komputer disambungkan ke rangkaian wayarles awam baharu, ujian yang sama dilakukan seperti untuk menyambung ke rangkaian persendirian. Kali ini, semua percubaan sambungan dijangka gagal kerana komputer mesti dilindungi daripada sebarang pengesanan luaran dan capaian pada rangkaian awam.

Metodologi ujian

Pengujian telah dijalankan pada PC percubaan yang menjalankan Windows XP berlesen dengan SP1 dipasang (ujian telah dijalankan di bawah keadaan ideal - "sistem pengendalian + Firewall" untuk mengecualikan pengaruh program lain terhadap kesucian eksperimen). Utiliti APS digunakan sebagai penunjuk capaian yang berjaya kepada perkhidmatan. Pengaruh luar berikut digunakan:

• pengimbas XSpider 6.5 dan 7.0
• Pengimbas Keselamatan Rangkaian Retina 4.9
• beberapa pengimbas reka bentuk saya.

Di samping itu, penghidu CommView 4.1 telah digunakan (sebagai cara memantau trafik rangkaian dan sebagai utiliti untuk menjana dan menghantar paket dengan pelbagai penyelewengan dalam struktur). Yang dipanggil banjir jenis biasa, utiliti untuk mensimulasikan program Trojan.

Pada PC ujian, IE 6, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1 digunakan sebagai cara untuk mengakses rangkaian dan Internet. Sebagai tambahan kepada mereka, ujian melibatkan simulator program Trojan dan program Trojan / Pintu Belakang sebenar daripada koleksi saya (khususnya Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), rangkaian / virus e-mel ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), pemuat turun Trojan (khususnya TrojanDownloader.IstBar) dan komponen SpyWare. Tugas utama ujian adalah untuk cuba melihat Firewall melalui mata pengguna, untuk melihat kekuatan dan kelemahannya dari sudut pandangan saya.

Kerio Technologies WinRoute Pro v4.2.5

Pemasangan dan nyahpasang:
Ia berjalan tanpa masalah.
Pemasangan dengan tetapan lalai, tiada peraturan - hanya NAT yang sah. Bekerja pada rangkaian - tiada masalah, hasil imbasan - APS tidak menunjukkan keadaan penggera, pengimbas percaya bahawa semua port ditutup. Winroute sendiri tidak mengeluarkan penggera dan tidak mengenal pasti secara visual fakta pengimbasan.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Pemasangan dan nyahpasang:
Pemasangan di bawah XP berjalan tanpa masalah apabila dimulakan, mod latihan diaktifkan.

ZoneLabs ZoneAlarm Pro dengan Penapisan Web 4.5.594.000 - Firewall Peribadi

Pemasangan dan nyahpasang:
Semasa pemasangan, XP ranap semasa cuba dimulakan selepas pemasangan. Selepas but semula semuanya berfungsi dengan baik.

AtGuard 3.22>

Pemasangan dan nyahpasang:
Pemasangan dan nyahpasang tidak menyebabkan sebarang masalah khas

Kelebihan:

1. Firewall bersaiz kecil, mempunyai penyelesaian yang menarik dari sudut pandangan antara muka - ia direka bentuk sebagai panel yang diletakkan di bahagian atas skrin

Kelemahan dan ciri:

1. Dalam mod latihan ia terdedah - dari saat permintaan untuk membuat peraturan dikeluarkan sehingga ia dibuat, ia menghantar paket dalam kedua-dua arah
2. Antara muka sedikit rosak semasa melukis semula tingkap

Kedudukan keseluruhan:
Firewall yang ringkas, tetapi agak berfungsi

Tembok Api Peribadi Kerio 4

Pemasangan dan nyahpasang:
Pemasangan diteruskan tanpa masalah, penyingkiran adalah "bersih" - tiada masalah diperhatikan selepas menyahpasang.

Norton Internet Security 2004 (NIS)

Pemasangan dan nyahpasang: Pemasangan tidak menyebabkan masalah, tetapi daripada semua yang dianalisis, pemasang adalah yang paling rumit.

Firewall Sambungan Internet, ICF - terbina dalam Tembok api Windows XP

Pemasangan dan nyahpasang: Tiada pemasangan diperlukan, ia adalah alat XP standard. Pendayaan dilakukan dalam tetapan penyesuai rangkaian. Secara lalai, ICF beroperasi dalam mod keselamatan maksimum dan (ini adalah hasil pemerhatian saya) prinsip operasinya adalah seperti berikut: permintaan aplikasi dikeluarkan secara luaran, dan hanya paket yang datang sebagai tindak balas kepada permintaan saya diterima secara luaran (permintaan -surat menyurat jawapan dikekalkan dengan jelas dalam bentuk jadual dinamik). Oleh itu, apabila mengimbas port pada komputer dengan ICF didayakan, tidak ada satu port terbuka (ini logik - paket pengimbas port tidak akan terlepas, kerana tiada siapa yang memintanya). Keadaannya sama dengan pelbagai jenis "nukes" berdasarkan penghantaran paket bukan standard

Tembok Api Sambungan Internet, ICF - tembok api terbina dalam untuk Windows XP SP2

Pemasangan dan nyahpasang: Tiada pemasangan diperlukan, ia adalah alat XP standard (termasuk dalam SP2 untuk XP). Pendayaan dilakukan dalam tetapan penyesuai rangkaian. Perlu diingatkan bahawa apabila memasang SP2 atau apabila memasang XP dengan SP2 bersepadu, sebagai tambahan kepada Firewall, pusat keselamatan muncul dalam sistem, yang boleh menunjukkan tetapan ICF

Sygate Personal Firewall Pro 5.5 binaan 2525

Pemasangan dan nyahpasang:

ISS BlackIce 3.6.cci

Pemasangan dan nyahpasang: Memasang dan menyahpasang program berlaku tanpa masalah, tetapi semasa pemasangan ralat berlaku dalam perpustakaan ikernel. Ralat yang sama berlaku semasa penyahpasangan. Kejadian ralat ini tidak menjejaskan proses memasang dan menyahpasang program. Pemasang tidak memerlukan but semula sistem, yang luar biasa untuk Firewall

Visnetic Firewall 2.2

Pemasangan dan nyahpasang: Memasang program dan menyahpasangnya berlaku tanpa masalah. Selepas pemasangan, but semula diperlukan.

Lihat dan hentikan tembok api peribadi 2.05

Pemasangan dan nyahpasang: Memasang program dan menyahpasangnya berlaku tanpa masalah. Selepas pemasangan, but semula diperlukan. Ia memasang pemacu sendiri untuk berfungsi.

Kaspersky AntiHacker 1.5

Pemasangan dan nyahpasang: Memasang program dan menyahpasangnya berlaku tanpa masalah. Selepas pemasangan, but semula diperlukan.

Tiny Personal Firewall Pro 6.0

Pemasangan dan nyahpasang:
Memasang program dan menyahpasangnya berlaku tanpa masalah. Selepas pemasangan, but semula diperlukan.

McAfee Personal Firewall Plus 6.0 Build 6014

Pemasangan dan nyahpasang:
Memasang program dan menyahpasangnya berlaku tanpa masalah. Selepas pemasangan, but semula diperlukan.

R-Firewall 1.0 Binaan 43

Pemasangan dan nyahpasang:
Memasang program dan menyahpasangnya berlaku tanpa masalah. Saiz pengedaran adalah kecil (3.8 MB), anda boleh menyesuaikan komposisi produk. Kerjanya agak stabil, tiada ranap atau pembekuan yang jelas dilihat pada PC rujukan

Kesimpulan dan kesimpulan umum

Jadi, mari kita ringkaskan keputusan ujian. Malah, ujian mengesahkan idea teori saya tentang keadaan masalah:

1. Firewall perlu dikonfigurasikan. Semua Firewall yang diuji berfungsi dengan baik, tetapi hanya selepas konfigurasi (latihan, membuat tetapan secara manual - tidak mengapa). Menggunakan Firewall yang tidak dikonfigurasikan boleh menyebabkan lebih banyak bahaya daripada kebaikan (ia akan membenarkan paket berbahaya melalui dan, sebaliknya, akan mengganggu program berguna);
2. Selepas menyediakan Firewall dan IDS anda perlu menguji- Ini juga merupakan kesimpulan yang agak jelas, tetapi ia adalah penting. Saya mengambil langkah pertama ke arah mencipta penguji - ini ialah utiliti APS. Terdapat dua lagi yang tinggal - simulator program Trojan (iaitu utiliti yang akan melakukan percubaan selamat untuk pengguna untuk "memecahkan" Firewall dari dalam (secara semula jadi, serangan akan diterangkan oleh pangkalan data dan akan dilakukan di pengguna perintah di bawah kawalannya), yang akan memungkinkan untuk memerhatikan tindak balas Firewall dan IDS) dan utiliti untuk pengimbasan port ekspres dan melakukan serangan asas (pada asasnya APS adalah betul-betul bertentangan - mereka boleh mempunyai pangkalan port yang sama). Saya sudah membangunkan utiliti ini - kehadiran mereka dalam senjata pengguna akan membolehkan beberapa jenis "kawalan instrumental".
3. Firewall Peribadi terdedah kepada perisian hasad yang dijalankan dari konteks program berguna. Kesimpulan - sekurang-kurangnya jauh dengan panel "kiri" yang berbeza dan BHO lain dari pelayar dan e-mel!! Sebelum memasang sebarang pemalam, panel, utiliti sambungan, dsb. anda perlu berfikir sepuluh kali tentang keperluan mereka, kerana... mereka bukan proses yang berasingan sistem operasi dan bekerja dari konteks program induk. Program Trojan mudah dikesan oleh Firewall peribadi - ia "melihat" bahawa proses tertentu (katakan, bo2k.exe) cuba mula mendengar pada port xxxxx atau berkomunikasi dengan hos tertentu - permintaan untuk kebenaran dikeluarkan, pengguna mula memikirkan jenis “bo2k.exe” itu " dan Pintu Belakang ditangkap. Tetapi jika program Trojan berfungsi dari konteks penyemak imbas, maka hampir pasti tiada siapa yang akan memberi perhatian kepada akses pelayar ke Internet. Program Trojan sebegini wujud, contoh terdekat ialah TrojanDownloader.IstBar - ia dipasang betul-betul sebagai panel IE (sememangnya ia tidak dalam proses, mahupun dalam senarai autorun);
4. Banyak Firewall peribadi kelihatan sebagai proses sistem pengendalian dan boleh dihentikan oleh virus. Kesimpulan - kerja Firewall perlu dipantau dan penamatannya secara tiba-tiba mungkin berfungsi sebagai isyarat bahawa virus telah menembusi PC;
5. Sesetengah Firewall (contohnya Kerio) membenarkan alat kawalan jauh- fungsi kawalan jauh mesti sama ada dilumpuhkan atau dilindungi kata laluan.

Artikel kedua ini menerangkan cara menyelesaikan masalah dengan penapis paket. Daripada membentangkan jadual siap dalam bentuk "masalah" - "penyelesaian", kaedah pendekatan sistematik diberikan untuk menyelesaikan masalah yang timbul.

Artikel kedua ini (dalam satu siri tiga) menerangkan cara menyelesaikan masalah penapis paket. Daripada membentangkan jadual siap dalam bentuk "masalah" - "penyelesaian", kaedah pendekatan sistematik disediakan untuk menyelesaikan masalah yang timbul.

pengenalan

Penapis paket melaksanakan dasar penapisan dengan memintas satu set peraturan dan, dengan itu, menyekat atau lulus paket. Bab ini menerangkan cara untuk mengesahkan bahawa dasar penapisan sedang dilaksanakan dengan betul dan cara mencari ralat jika tidak.

Secara umum, dalam kursus bab ini kita akan membandingkan tugas menulis satu set peraturan penapisan dengan pengaturcaraan. Jika anda tidak mempunyai kemahiran pengaturcaraan, maka perbandingan ini akan kelihatan agak rumit kepada anda. Tetapi peraturan menulis itu sendiri tidak memerlukan kehadiran ijazah akademik dalam "sains komputer" atau pengalaman pengaturcaraan, bukan?

Jawapannya tidak, anda mungkin tidak memerlukannya. Bahasa yang digunakan untuk mengkonfigurasi penapis paket dibuat serupa dengan bahasa manusia. Sebagai contoh:

sekat semua

pengsan semua keep state

masukkan proto tcp ke mana-mana port www keep state

Malah, anda tidak perlu mempunyai pengaturcara berdekatan untuk memahami perkara yang dilakukan oleh set ini atau menggunakan gerak hati anda untuk menulis dasar penapisan yang serupa. Malah terdapat kemungkinan besar bahawa satu set peraturan penapisan yang dibuat dalam rupa ini akan melaksanakan tindakan yang ada dalam fikiran pengarangnya.

Malangnya, komputer hanya melakukan apa yang anda minta mereka lakukan, bukan apa yang anda mahu mereka lakukan. Lebih teruk lagi, mereka tidak akan dapat membezakan yang dikehendaki daripada yang sebenar, jika terdapat perbezaan tersebut. Ini bermakna jika komputer tidak melakukan apa yang anda mahu dengan betul, walaupun anda fikir anda telah menerangkan arahan dengan jelas, ia berada di tangan anda untuk mencari perbezaan dan menukar arahan. Dan kerana ini masalah biasa dalam pengaturcaraan, kita boleh melihat bagaimana pengaturcara menangani perkara ini. Di sinilah ternyata bahawa kemahiran dan kaedah yang digunakan untuk menguji dan menyahpepijat atur cara dan peraturan penapisan adalah sangat serupa. Namun di sini anda tidak memerlukan pengetahuan tentang mana-mana bahasa pengaturcaraan untuk memahami implikasi untuk ujian dan penyahpepijatan.

Dasar penapisan yang baik.

Dasar penapisan ialah spesifikasi tidak formal tentang perkara yang kita inginkan daripada tembok api. Sebaliknya, satu set peraturan, pelaksanaan spesifikasi, adalah satu set arahan standard, program yang dilaksanakan oleh mesin. Sehubungan itu, untuk menulis program, anda mesti menentukan apa yang perlu dilakukan.

Jadi langkah pertama dalam konfigurasi tembok api adalah untuk menentukan secara tidak rasmi perkara yang anda ingin capai. Sambungan yang manakah harus disekat atau dibenarkan?

Contohnya ialah:

Terdapat tiga rangkaian yang mesti dipisahkan antara satu sama lain oleh tembok api. Sebarang sambungan dari satu rangkaian ke rangkaian yang lain melalui tembok api. Firewall mempunyai 3 antara muka, setiap satunya disambungkan ke rangkaian yang sepadan:

$ext_if - ke rangkaian luaran.

$dmz_if - DMZ dengan pelayan.

$lan_if - LAN dengan stesen kerja.

Hos pada LAN harus bebas untuk menyambung kepada mana-mana hos dalam DMZ atau rangkaian luaran.

Pelayan dalam DMZ mesti boleh berkomunikasi secara bebas dengan hos pada rangkaian luaran. Hos rangkaian luaran hanya boleh menyambung ke pelayan berikut dalam DMZ:

Pelayan web 10.1.1.1 port 80

Pelayan mel 10.2.2.2 port 25

Semua sambungan lain hendaklah dilarang (contohnya, daripada mesin pada rangkaian luaran kepada mesin pada LAN).

Dasar ini dinyatakan secara tidak formal supaya sesiapa yang membacanya dapat memahaminya. Ia sepatutnya sangat spesifik sehingga pembaca boleh dengan mudah merumuskan jawapan kepada soalan seperti 'Adakah sambungan dari hos X ke hos Y dibenarkan masuk (atau keluar) pada antara muka Z?'. Jika anda tertanya-tanya sama ada polisi anda tidak memenuhi keperluan ini, ini kerana ia tidak ditakrifkan dengan baik.

Dasar "kabur" seperti "benarkan semua yang penting" atau "sekat serangan" perlu dijelaskan atau anda tidak akan dapat menggunakan atau mengesahkannya. Seperti dalam pembangunan perisian, tugas yang tidak diformalkan dengan baik jarang membawa kepada pelaksanaan yang wajar atau betul. ("Kenapa anda tidak mula menulis kod, sementara saya memikirkan apa yang pelanggan perlukan").

Satu set peraturan yang melaksanakan dasar

Set peraturan ditulis sebagai fail teks yang mengandungi ayat dalam bahasa formal. Sama seperti kod sumber diproses dan diterjemahkan ke dalam arahan kod mesin oleh pengkompil, "teks sumber" set peraturan diproses oleh pfctl dan hasilnya ditafsirkan oleh pf dalam kernel.

Apabila kod sumber melanggar peraturan bahasa formal, penganalisis melaporkan ralat sintaks dan enggan memproses fail selanjutnya. Ralat ini ialah ralat masa kompilasi dan biasanya boleh diperbaiki dengan cepat. Apabila pfctl tidak dapat menghuraikan fail set peraturan anda, ia mencetak baris yang mengandungi ralat dan mesej yang lebih kurang bermaklumat tentang perkara yang tidak dapat dihuraikannya. Sehingga keseluruhan fail diproses tanpa ralat tunggal, pfctl tidak akan mengubah set peraturan sebelumnya dalam kernel. Dan kerana fail itu mengandungi satu atau lebih ralat sintaks, tidak akan ada "program" yang boleh dilaksanakan oleh pf.

Jenis ralat kedua dipanggil "ralat masa larian" kerana ia berlaku apabila atur cara yang ditulis dengan betul secara sintaksis berjaya diterjemahkan dan dilaksanakan. Secara umum, dalam bahasa pengaturcaraan, ini boleh berlaku apabila program membahagi dengan sifar, cuba mengakses kawasan memori yang tidak sah atau kehabisan memori. Tetapi oleh kerana set peraturan hanya samar-samar menyerupai fungsi bahasa pengaturcaraan, kebanyakan ralat ini tidak boleh berlaku semasa penggunaan peraturan, contohnya, peraturan tidak boleh menyebabkan apa yang dipanggil. "sistem ranap", seperti yang dilakukan oleh program biasa. Walau bagaimanapun, satu set peraturan boleh menyebabkan ralat yang sama, dalam bentuk menyekat atau, sebaliknya, membenarkan paket yang tidak mematuhi dasar. Ini kadangkala dipanggil ralat logik, ralat yang tidak membuang pengecualian atau berhenti, tetapi hanya menghasilkan keputusan yang salah.

Jadi, sebelum kita boleh mula menyemak sama ada tembok api melaksanakan dasar keselamatan kita dengan betul, kita mesti berjaya memuatkan set peraturan terlebih dahulu.

Ralat penganalisis

Ralat penganalisis berlaku apabila cuba memuatkan senarai peraturan menggunakan pfctl, contohnya:

# pfctl -f/dan lain-lain/pf.conf

/ dan lain-lain/pf.conf:3:sintaksralat

Mesej ini menunjukkan bahawa terdapat ralat sintaks pada baris 3 /etc/pf.conf dan pfctl tidak boleh memuatkan peraturan. Set dalam kernel tidak berubah, ia tetap sama seperti sebelum cuba memuatkan yang baru.

Terdapat banyak jenis ralat yang dihasilkan oleh pfctl. Untuk bermula dengan pfctl, anda hanya perlu membacanya dengan teliti. Mungkin tidak semua bahagian mesej akan mendedahkan maksudnya kepada anda dengan segera, tetapi anda perlu membaca semuanya, kerana... Ini akan memudahkan untuk memahami perkara yang salah kemudiannya. Jika mesej mengandungi sebahagian daripada borang "nama fail:nombor:teks", ia merujuk kepada baris dengan nombor yang sepadan dalam fail yang ditentukan.

Langkah seterusnya ialah melihat baris keluaran menggunakan editor teks (dalam vi anda boleh pergi ke baris 3 dengan menaip 3G dalam mod bip), atau seperti ini:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 blok semua

3 pengsan pada $int_if inet semua keadaan kekal

pengsan inet pada $int_if all kep state

Masalahnya mungkin kesilapan menaip yang mudah, seperti dalam kes ini ("kep" bukannya "simpan"). Selepas membetulkan, cuba muat semula fail:

# pfctl -f/dan lain-lain/pf.conf

/ dan lain-lain/pf.conf:3:sintaksralat

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

pengsan inet pada $int_if all keep state

Kini semua kata kunci adalah betul, tetapi apabila diperiksa dengan lebih teliti, kami mendapati bahawa peletakan kata kunci "inet" sebelum "pada $int_if" adalah tidak betul. Ini menggambarkan bahawa baris yang sama boleh mengandungi lebih daripada satu ralat. Pfctl mencetak ralat pertama yang ditemuinya dan berhenti melaksanakan. Jika nombor baris yang sama dikeluarkan semasa dimulakan semula, ini bermakna masih terdapat ralat di dalamnya, atau yang sebelumnya tidak dibetulkan dengan betul.

Kata kunci yang diletakkan dengan tidak betul juga merupakan kesilapan biasa. Ini boleh didedahkan dengan membandingkan peraturan dengan sintaks BNF rujukan di hujung fail bantuan man pf.conf(5), yang mengandungi:

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

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

[ "pada" ifspec ] [ route ] [ af ] [ protospec ]

hos [senarai-penapis]

ifspec = ([ "!" ] nama antara muka) | "(" senarai antara muka ")"

af = "inet" | "inet6"

Apa maksudnya kata kunci“inet” mesti mengikut “pada $int_if”

Mari kita betulkan dan cuba lagi:

# pfctl -f/dan lain-lain/pf.conf

/ dan lain-lain/pf.conf:3:sintaksralat

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

pengsan pada $int_if inet semua kekalkan keadaan

Tiada ralat yang jelas lagi sekarang. Tetapi kami tidak melihat semua butiran yang disertakan! Garis bergantung pada definisi makro $inf_if. Apakah yang boleh ditakrifkan secara salah?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

blok drop semua

/etc/pf.conf:3: ralat sintaks

Selepas membetulkan kesilapan taip "fxp 0" kepada "fxp0", cuba lagi:

# pfctl -f/dan lain-lain/pf.conf

Ketiadaan mesej menunjukkan bahawa fail telah berjaya dimuat turun.

Dalam sesetengah kes, pfctl mungkin menghasilkan mesej ralat yang lebih khusus daripada hanya "ralat sintaks":

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port hanya digunakan pada tcp/udp

/etc/pf.conf:3: melangkau peraturan kerana ralat

/etc/pf.conf:3: peraturan berkembang kepada tiada gabungan yang sah

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

pengsan pada $int_if ke port ssh keep state

Baris pertama mesej ralat adalah yang paling bermaklumat berbanding yang lain. Dalam kes ini, masalahnya ialah peraturan, apabila menentukan port, tidak menentukan protokol - tcp atau udp.

Dalam kes yang jarang berlaku, pfctl akan menjadi keliru dengan kehadiran aksara yang tidak boleh dicetak atau ruang yang tidak diperlukan dalam fail, ralat tersebut tidak mudah untuk dikesan tanpa pemprosesan khas fail:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: ruang putih selepas \

/etc/pf.conf:2: ralat sintaks

# cat -ent /etc/pf.conf

1 blok semua$

2 pengsan pada gem0 daripada mana-mana kepada mana-mana \ $

3 ^ Saya simpannegeri$

Masalahnya di sini ialah watak ruang, selepas garis miring ke belakang tetapi sebelum penghujung baris kedua, ditunjukkan oleh tanda "$" dalam output cat -e.

Sebaik sahaja set peraturan telah berjaya dimuatkan, adalah baik untuk melihat hasilnya:

$ cat /etc/pf.conf

sekat semua

# lulus dari mana-mana kepada mana-mana \

lulus dari 10.1.2.3 kepada mana-mana

$ pfctl -f /etc/pf.conf

$ pfctl -sr

blokjatuhkansemua

"Sentak ke belakang" pada penghujung baris ulasan sebenarnya bermakna baris ulasan akan diteruskan di bawah.

Mengembangkan senarai yang disertakan dalam pendakap kerinting () boleh menghasilkan hasil yang mungkin mengejutkan anda, dan pada masa yang sama menunjukkan set peraturan yang diproses oleh penganalisis:

$ cat /etc/pf.conf

lulus dari ( !10.1.2.3, !10.2.3.4 ) kepada mana-mana

$ pfctl -nvf /etc/pf.conf

lulus internet dari ! 10.1.2.3 kepada mana-mana

lulus internet dari ! 10.2.3.4kepadamana-mana

Tangkapan di sini ialah ungkapan "( !10.1.2.3, !10.2.3.4 )" tidak akan bermaksud "semua alamat kecuali 10.1.2.3 dan 10.2.3.4", ungkapan yang diperluaskan itu sendiri bermaksud sepadan dengan mana-mana alamat yang mungkin.

Anda harus memuatkan semula set peraturan anda selepas membuat perubahan kekal untuk memastikan pfctl boleh memuatkannya apabila mesin dibut semula. Pada OpenBSD, skrip permulaan rc dalam /etc/rc mula-mula memuatkan set peraturan lalai kecil yang menyekat semua trafik kecuali yang diperlukan semasa fasa but (seperti dhcp atau ntp). Jika skrip tidak dapat memuatkan set peraturan sebenar daripada /etc/pf.conf disebabkan oleh ralat sintaks yang diperkenalkan sebelum mesin dibut semula tanpa menyemak, maka set lalai akan kekal aktif. Nasib baik, set ini membenarkan sambungan ssh masuk, jadi masalah itu boleh diselesaikan dari jauh.

Menguji

Memandangkan kami mempunyai dasar yang ditakrifkan dengan sangat tepat dan satu set peraturan yang harus melaksanakannya, maka istilah ujian akan bermakna dalam kes kami pematuhan set yang terhasil dengan dasar yang diberikan.

Terdapat hanya dua cara untuk peraturan berfungsi dengan tidak betul: menyekat sambungan yang sepatutnya dibenarkan, dan sebaliknya, membenarkan sambungan yang sepatutnya disekat.

Pengujian secara umum membayangkan pendekatan sistematik kepada penciptaan teratur pelbagai jenis sambungan. Tidak mustahil untuk menyemak segala-galanya kombinasi yang mungkin sumber/penerima dan port yang sepadan pada antara muka, kerana firewall secara teorinya boleh menemui sejumlah besar kombinasi sedemikian. Memastikan ketepatan awal set peraturan hanya boleh dipastikan untuk sangat kes mudah. Dalam amalan, penyelesaian terbaik ialah membuat senarai sambungan ujian berdasarkan dasar keselamatan, supaya setiap item dasar terjejas. Jadi, untuk contoh dasar kami, senarai ujian adalah seperti berikut:

Sambungan dari LAN ke DMZ (mesti dilangkau)

dari LAN ke rangkaian luaran (mesti dilangkau)

dari DMZ ke LAN (mesti disekat)

dari DMZ ke rangkaian luaran (mesti dilangkau)

daripada rangkaian luaran ke DMZ ke 10.1.1.1 pada port 80 (mesti dilangkau)

dari rangkaian luaran ke DMZ ke 10.1.1.1 pada port 25 (harus disekat)

dari rangkaian luaran ke DMZ ke 10.2.2.2 pada port 80 (harus disekat)

dari rangkaian luaran ke DMZ ke 10.2.2.2 pada port 25 (mesti dilangkau)

dari rangkaian luaran ke LAN (mesti disekat)

Hasil yang dijangkakan mesti ditakrifkan dalam senarai ini sebelum ujian bermula.

Ini mungkin terdengar aneh, tetapi tujuan setiap ujian adalah untuk mencari ralat dalam pelaksanaan satu set peraturan firewall, dan bukan hanya untuk menyatakan ketiadaannya. Dan matlamat utama proses ini adalah untuk membina satu set peraturan tanpa ralat, jadi jika anda fikir mungkin terdapat ralat, anda lebih baik mencarinya daripada kehilangannya. Dan jika anda mengambil peranan sebagai penguji, anda harus mematuhi gaya pemikiran yang merosakkan dan cuba memintas sekatan tembok api. Dan hanya fakta bahawa sekatan tidak boleh dilanggar akan menjadi pengesahan beralasan bahawa set peraturan tidak mengandungi ralat.

Sambungan TCP dan UDP boleh disemak menggunakan nc. nc boleh digunakan sebagai pelanggan dan pelayan (menggunakan pilihan -l). Dan untuk permintaan dan respons ICMP, pelanggan terbaik untuk diperiksa ialah ping.

Untuk menyemak sama ada sambungan disekat, anda boleh menggunakan sebarang cara yang akan cuba membuat sambungan ke pelayan.

Menggunakan alat pengumpulan port seperti nmap, anda boleh mengimbas berbilang port dengan mudah, walaupun merentas berbilang hos. Jika keputusan tidak kelihatan agak jelas, lihat halaman manual. Sebagai contoh, untuk port TCP, pengimbas mengembalikan nilai 'tidak ditapis' apabila nmap menerima RST daripada pf. Selain itu, pf yang dipasang pada mesin yang sama seperti pengimbas boleh mempengaruhi operasi nmap yang betul.

Alat pengimbasan yang lebih canggih mungkin termasuk alat untuk mencipta paket IP yang berpecah-belah atau tidak betul.

Untuk mengesahkan bahawa penapis menghantar sambungan yang dinyatakan dalam dasar, kaedah terbaik ialah menyemak menggunakan aplikasi tersebut yang akan digunakan oleh pelanggan kemudiannya. Oleh itu, menyemak laluan sambungan http dari mesin klien pelayan web yang berbeza, serta dari penyemak imbas yang berbeza, dan pensampelan kandungan yang berbeza adalah lebih baik daripada sekadar mengesahkan penubuhan sesi TCP kepada nc, yang berfungsi sebagai bahagian pelayan. Pelbagai faktor, seperti sistem pengendalian hos, juga boleh menyebabkan ralat - masalah dengan penskalaan tetingkap TCP atau respons TCP SACK antara sistem pengendalian tertentu.

Apabila titik ujian seterusnya diluluskan, keputusannya mungkin tidak selalu sama. Sambungan mungkin terganggu semasa proses penubuhan sambungan jika firewall mengembalikan RST. Penubuhan sambungan mungkin gagal disebabkan oleh tamat masa. Sambungan mungkin diwujudkan sepenuhnya dan berfungsi, tetapi selepas beberapa ketika ia mungkin membeku atau putus. Sambungan mungkin bertahan, tetapi daya pemprosesan atau kependaman mungkin berbeza daripada yang dijangkakan, lebih tinggi atau lebih rendah (sekiranya anda menggunakan AltQ untuk mengehadkan lebar jalur).

Seperti hasil yang dijangkakan, selain melangkau/menyekat sambungan, anda juga boleh ambil perhatian sama ada paket dilog, cara ia diterjemahkan, dihalakan dan sama ada kaunter yang diperlukan dinaikkan, jika perlu. Jika aspek ini penting kepada anda, maka ia juga perlu disertakan dalam metodologi ujian.

Dasar anda mungkin termasuk keperluan yang berkaitan dengan prestasi, tindak balas terhadap beban berlebihan dan toleransi kesalahan. Dan mereka mungkin memerlukan ujian berasingan. Jika anda menyediakan sistem toleransi kesalahan menggunakan CARP, anda mungkin ingin mengetahui perkara yang berlaku di bawah pelbagai jenis kegagalan.

Apabila anda memerhatikan keputusan yang berbeza daripada apa yang anda jangkakan, ambil nota langkah demi langkah tentang langkah anda semasa ujian, perkara yang anda jangkakan, sebab anda menjangkakannya, keputusan yang anda perolehi dan bagaimana keputusan itu berbeza daripada jangkaan anda. Ulangi ujian untuk melihat sama ada keadaan adalah sama atau berbeza dari semasa ke semasa. Cuba tukar parameter input ujian (alamat sumber/destinasi atau port).

Dari saat anda mengalami masalah yang boleh diterbitkan semula, anda perlu mula menyahpepijat untuk mengetahui sebab perkara tidak berfungsi seperti yang anda jangkakan dan cara "membetulkan" perkara. Dengan persediaan ini, anda harus menukar set peraturan dan ulangi semua ujian, termasuk ujian yang tidak menimbulkan ralat, kerana dengan menukar peraturan, anda secara tidak sengaja boleh menjejaskan operasi bahagian set peraturan yang berfungsi dengan betul.

Prinsip yang sama berlaku untuk perubahan lain yang dibuat pada set. begitu prosedur formal semakan akan membantu menjadikan proses kurang terdedah untuk memperkenalkan ralat. Perubahan kecil mungkin tidak memerlukan pengulangan keseluruhan prosedur, tetapi jumlah beberapa perubahan kecil mungkin menjejaskan hasil keseluruhan pemprosesan set. Anda boleh menggunakan sistem kawalan versi seperti cv untuk bekerja dengan fail konfigurasi anda kerana... ini akan membantu dalam menyiasat perubahan yang membawa kepada ralat. Jika anda tahu bahawa pepijat tidak berlaku seminggu yang lalu, tetapi ia berlaku sekarang, melihat semua perubahan yang anda buat sepanjang minggu lepas akan membantu anda melihat masalah itu, atau sekurang-kurangnya kembali ke titik di mana ia tidak tidak wujud.

Set peraturan bukan remeh boleh dianggap sebagai program; mereka jarang sempurna dalam versi pertama mereka, dan memerlukan masa untuk yakin bahawa mereka bebas daripada ralat. Walau bagaimanapun, tidak seperti program biasa, yang tidak pernah dianggap bebas ralat oleh kebanyakan pengaturcara, set peraturan masih cukup mudah untuk mendekati definisi ini.

Penyahpepijatan

Istilah debugging biasanya merujuk kepada mencari dan menghapuskan ralat pengaturcaraan dalam program komputer. Atau, dalam konteks set peraturan firewall, istilah ini akan merujuk kepada proses mencari sebab mengapa set itu tidak mengembalikan hasil yang diingini. Terdapat beberapa jenis ralat yang boleh muncul dalam peraturan, bagaimanapun, kaedah untuk mencarinya adalah serupa dengan pengaturcaraan.

Sebelum anda mula mencari punca masalah, anda mesti memahami dengan jelas sifat masalah tersebut. Jika anda melihat ralat itu sendiri semasa ujian, ia sangat mudah. Tetapi jika orang lain melaporkan pepijat kepada anda, mencipta matlamat yang jelas daripada laporan pepijat yang tidak tepat boleh mencabar. Tempat terbaik untuk bermula ialah dengan menghasilkan semula ralat itu sendiri.

Masalah rangkaian mungkin tidak selalu disebabkan oleh penapis paket. Sebelum anda menumpukan perhatian anda pada penyahpepijatan konfigurasi pf, anda perlu memastikan bahawa masalah itu disebabkan oleh penapis paket. Ini mudah dilakukan dan juga akan menjimatkan masa mencari masalah di tempat lain. Hanya matikan pf dengan pfctl -d dan semak sama ada masalah itu berlaku lagi. Jika ya, dayakan pf dengan pfctl -e dan lihat apa yang berlaku. Kaedah ini tidak akan berfungsi dalam beberapa kes, contohnya, jika pf tidak melakukan terjemahan alamat rangkaian (NAT) dengan betul, maka mematikan pf jelas tidak akan menyingkirkan ralat. Tetapi dalam kes di mana ini mungkin, cuba pastikan ia adalah penapis paket yang bersalah.

Oleh itu, jika masalah adalah dalam penapis paket, perkara pertama yang perlu anda lakukan ialah memastikan bahawa pf benar-benar berfungsi dan set peraturan yang diperlukan berjaya dimuatkan:

# pfctl -si | Status grep

Status: Didayakan selama 4 hari 13:47:32Nyahpepijat: Segera

# pfctl -sr

lulus cepat pada lo0 semua

lulus cepat pada enc0 semua

Penyahpepijatan mengikut protokol

Langkah penyahpepijatan seterusnya adalah untuk menentukan masalah kepada sambungan rangkaian tertentu. Jika anda mempunyai mesej: "Pemesejan segera dalam aplikasi X tidak berfungsi," anda perlu mengetahui sambungan rangkaian yang sedang digunakan. Kesimpulannya mungkin seperti "hos A tidak dapat mewujudkan sambungan ke hos B pada port C." Kadangkala tugas ini adalah yang paling sukar, tetapi jika anda mempunyai maklumat tentang sambungan yang diperlukan dan anda tahu bahawa tembok api tidak akan membenarkannya, anda hanya perlu menukar peraturan untuk menyelesaikan masalah ini.

Terdapat beberapa cara untuk mengetahui protokol atau sambungan yang digunakan oleh aplikasi. Tcpdump boleh memaparkan paket yang tiba atau meninggalkan kedua-dua antara muka rangkaian sebenar dan yang maya seperti pflog dan pfsync. Anda boleh mentakrifkan ungkapan penapis untuk menentukan paket yang hendak dipaparkan dan menghapuskan hingar rangkaian luar. Cuba buat sambungan rangkaian dalam aplikasi yang dikehendaki dan lihat pada paket yang dihantar. Sebagai contoh:

# 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,wscale 0> (DF)

Ini ialah paket TCP SYN, paket pertama jabat tangan TCP.

Pengirim ialah 10.1.2.3 port 65123 (kelihatan seperti port rawak yang tidak mempunyai keistimewaan) dan penerima ialah 10.2.3.4 port 6667. Penjelasan terperinci tentang format output tcpdump boleh didapati dalam halaman manual utiliti. Tcpdump ialah alat yang paling penting untuk menyahpepijat masalah berkaitan pf dan sangat penting untuk membiasakannya.

Kaedah lain ialah menggunakan ciri pengelogan pf. Dengan mengandaikan anda menggunakan pilihan 'log' dalam semua peraturan dengan 'blok', maka semua paket yang disekat oleh pf akan ditunjukkan dalam log. Adalah mungkin untuk mengalih keluar pilihan 'log' daripada peraturan yang berurusan dengan protokol yang diketahui, mis. Hanya paket yang pergi ke port yang tidak diketahui akan direkodkan dalam log. Cuba gunakan aplikasi yang tidak dapat disambungkan dan lihat pflog:

# ifconfig pflog0 ke atas

# tcpdump -netti pflog0

26 Nov 00:02:26.723219 peraturan 41/0(perlawanan): sekat masuk pada isyarat0:

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

16384 (DF)

Jika anda menggunakan pflog, daemon yang sentiasa mendengar pflog0 dan menyimpan maklumat yang diterima dalam /var/log/pflog, anda boleh melihat maklumat yang disimpan seperti ini:

# tcpdump -nettr/var/log/pflog

Apabila mengeluarkan paket pf yang disimpan, anda boleh menggunakan ungkapan penapisan tambahan, contohnya, lihat paket yang disekat pada input pada antara muka wi0:

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

Sesetengah protokol, seperti FTP, tidak begitu mudah untuk dijejaki kerana ia tidak menggunakan nombor port tetap atau menggunakan berbilang sambungan yang wujud bersama. Ia mungkin tidak mungkin untuk mendapatkannya melalui tembok api tanpa membuka pelbagai port. Untuk protokol individu, terdapat penyelesaian yang serupa dengan ftp-proxy.

Peraturan nyahpepijat

Jika set peraturan anda menyekat protokol tertentu kerana anda belum membuka port yang betul, ia masalah yang lebih besar peringkat reka bentuk dan bukannya pepijat dalam peraturan. Tetapi bagaimana jika anda melihat bahawa sambungan yang anda mempunyai peraturan membenarkannya disekat?

Sebagai contoh, set anda mengandungi peraturan

blok dalam return-first pada $ext_if proto tcp daripada mana-mana kepada $ext_if port ssh

Tetapi apabila anda cuba menyambung ke port TCP 22, sambungan itu diterima! Nampaknya tembok api mengabaikan peraturan anda. Sama seperti menyusun teka-teki, terdapat penjelasan yang logik dan biasanya remeh untuk perkara ini pada kali pertama anda menemuinya.

Mula-mula, anda harus menyemak semua langkah yang dinyatakan sebelum ini. Sebagai contoh, mari kita anggap bahawa tembok api sedang berjalan dan mengandungi peraturan yang diberikan di atas. Tidak mungkin kebimbangan kami sebelum ini adalah benar, tetapi mudah untuk menyemak:

# pfctl -si | Status grep

Status: Didayakan selama 4 hari 14:03:13Nyahpepijat: Segera

# pfctl -gsr | grep "port=ssh"

@14 blok kembali-pertama masuk pada kue0 inet proto tcp daripada mana-mana kepada 62.65.145.30 port = ssh

Perkara seterusnya yang kami ada ialah: Sambungan TCP diterima pada port 22 pada kue0. Anda mungkin berfikir bahawa ini sudah jelas, tetapi ia patut diperiksa. Jalankan tcpdump:

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

Sekarang cuba semula sambungan SSH. Anda sepatutnya melihat paket daripada sambungan anda dalam output tcpdump. Anda mungkin tidak melihatnya, dan ini mungkin kerana sambungan sebenarnya tidak melalui kue0, tetapi melalui antara muka yang berbeza, yang menerangkan sebab peraturan tidak dicetuskan. Atau anda mungkin menyambung ke alamat lain. Ringkasnya, jika anda tidak melihat paket ssh, maka pf juga tidak akan melihatnya, dan ia mungkin tidak dapat menyekatnya menggunakan peraturan yang diberikan dalam masalah kami.

Tetapi jika anda melihat paket menggunakan tcpdump, pf akan "melihat" mereka juga dan akan menapisnya. Andaian seterusnya ialah peraturan menyekat bukan sahaja mesti ada dalam set (yang telah kami tetapkan), tetapi mestilah peraturan padanan terakhir untuk paket yang dikehendaki. Jika ini bukan peraturan muktamad, maka jelas keputusan untuk memegang paket tidak dibuat mengikut ini.

Dalam kes apakah peraturan mungkin bukan peraturan padanan terakhir? Terdapat tiga sebab yang mungkin:

A) peraturan tidak berfungsi, kerana melihat peraturan tidak mencapai apa yang kita perlukan.

Peraturan yang ada sebelum ini juga dicetuskan dan menyebabkan pelaksanaan ditamatkan dengan pilihan 'cepat';

B) peraturan diproses, tetapi peraturan itu tidak berfungsi kerana ketidakpadanan kriteria individu.

C) peraturan diproses, peraturan dicetuskan, tetapi pemprosesan diteruskan dan peraturan seterusnya juga dicetuskan untuk paket.

Untuk menolak ketiga-tiga kes ini, anda boleh, melihat set peraturan yang dimuatkan, bayangkan secara mental memproses paket TCP hipotetikal yang tiba pada antara muka kue0 dan port 22. Pilih blok untuk dinyahpepijat. Mula merangkak dengan peraturan pertama. Adakah ia sepadan? Jika ya, tandakannya. Adakah ia mempunyai pilihan 'cepat'? Jika ya, maka kita berhenti berkeliling. Jika tidak, teruskan dengan peraturan seterusnya. Ulang semak sehingga padanan ditemui dengan pilihan 'cepat' atau penghujung set peraturan dicapai. Peraturan mana yang sepadan terakhir? Jika ia bukan peraturan nombor 14, anda telah menemui penjelasan untuk masalah tersebut.

Melangkau peraturan secara manual mungkin kelihatan menyeronokkan, bagaimanapun, dengan pengalaman yang mencukupi ia boleh dilakukan dengan cepat dan sebahagian besarnya kebolehpercayaan. Jika set itu cukup besar, anda boleh mengurangkannya buat sementara waktu. Simpan salinan senarai peraturan sebenar dan padamkan entri yang anda fikir tidak akan menjejaskan keputusan. Muat turun set ini dan uji lagi. Jika sambungan kini disekat, maka peraturan yang kelihatan tidak berkaitan dengan paket yang anda cari bertanggungjawab untuk kes A atau B. Tambahkan peraturan satu demi satu, ulangi ujian sehingga anda menemui yang anda perlukan. Jika sambungan masih diluluskan selepas mengalih keluar peraturan yang tidak menjejaskannya, ulangi laluan mental bagi set yang dikurangkan.

Kaedah lain ialah menggunakan keupayaan pengelogan pf untuk mengenal pasti kes A atau C. Tambahkan 'log' pada semua peraturan dengan 'lulus cepat' sebelum peraturan ke-14. Tambahkan 'log' pada semua peraturan dengan 'lulus' selepas peraturan ke-14. Jalankan tcpdump untuk antara muka pflog0 dan wujudkan sambungan ssh. Anda akan melihat peraturan selain 14 yang dicetuskan terakhir pada paket anda. Jika tiada apa-apa dalam log, maka kes B berlaku.

Menjejak sambungan melalui tembok api

Apabila sambungan melalui tembok api, paket tiba pada satu antara muka dan dihantar keluar melalui yang kedua. Respons datang ke antara muka kedua dan pergi ke yang pertama. Oleh itu, sambungan boleh gagal dalam setiap empat kes ini.

Pertama, anda mesti memikirkan yang mana antara empat kes yang menjadi masalah. Jika anda cuba membuat sambungan, anda akan melihat paket TCP SYN pada antara muka pertama menggunakan tcpdump. Anda juga harus melihat output paket TCP SYN yang sama daripada antara muka kedua. Jika anda tidak melihatnya, maka kami membuat kesimpulan bahawa pf menyekat paket masuk pada antara muka pertama, atau paket keluar pada kedua.

Jika penghantaran SYN tidak disekat, anda akan melihat SYN+ACK datang ke antara muka kedua dan meninggalkan yang pertama. Jika tidak, pf menyekat SYN+ACK pada beberapa antara muka.

Tambahkan pilihan 'log' pada peraturan yang sepatutnya membenarkan SYN dan SYN+ACK pada kedua-dua antara muka, serta peraturan yang harus menyekatnya. Cuba semula sambungan dan semak pflog. Ia harus menjelaskan dalam hal apa penyekatan itu berlaku dan dengan peraturan apa.

Menyahpepijat keadaan sambungan

Sebab yang paling biasa untuk paket pf disekat ialah terdapat peraturan penyekatan berlebihan dalam set. Peraturan padanan terakhir yang sepadan boleh didapati dengan menambahkan pilihan 'log' pada semua peraturan yang berpotensi memberi kesan dan mendengar antara muka pflog.

Dalam bilangan kes yang lebih kecil, ia berlaku bahawa pf secara senyap menjatuhkan paket berdasarkan bukan peraturan, dan di sini menambahkan 'log' kepada semua peraturan tidak akan menyebabkan paket yang digugurkan berakhir di pflog. Selalunya satu paket hampir, tetapi tidak sepenuhnya, dipadankan dengan entri negeri.

Ingat bahawa untuk setiap paket yang diproses, penapis paket mengimbas jadual keadaan. Jika entri yang sepadan ditemui, paket akan dibenarkan dengan serta-merta tanpa menyebabkan set peraturan diproses untuk dirinya sendiri.

Entri jadual keadaan mengandungi maklumat khusus untuk satu sambungan.

Setiap entri mempunyai kunci unik. Kunci ini terdiri daripada beberapa nilai yang mengehadkan jangka hayat sambungan kepada pemalar sepanjang. 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 kepunyaan sambungan yang sama, dan paket daripada sambungan yang berbeza akan sentiasa mempunyai kunci yang berbeza.

Apabila entri jadual keadaan dibuat menggunakan pilihan 'keep state' daripada peraturan, entri sambungan disimpan menggunakan kekunci sambungan. Had penting untuk jadual keadaan ialah semua kunci mestilah unik. Itu. tidak boleh ada dua rekod dengan kunci yang sama.

Ia mungkin tidak serta-merta jelas bahawa dua hos yang sama tidak boleh mewujudkan berbilang sambungan wujud bersama menggunakan alamat, protokol dan port yang sama, tetapi ini adalah sifat asas kedua-dua TCP dan UDP. Malah, tindanan TCP/IP hanya boleh mengaitkan paket individu dengan soketnya dengan melakukan pemilihan berdasarkan alamat dan port.

Walaupun sambungan ditutup, sepasang alamat dan port yang sama tidak boleh digunakan semula dengan serta-merta. Peralatan rangkaian kemudiannya mungkin menghantar paket yang dihantar semula, dan jika timbunan TCP/IP penerima tersilap sebagai paket daripada sambungan yang baru dibuat, ini akan mengganggu atau bahkan memutuskan sambungan baharu. Atas sebab ini, kedua-dua hos mesti menunggu tempoh masa tertentu, dipanggil 2MSL ("dua kali ganda sepanjang hayat segmen maksimum"), sebelum boleh menggunakan alamat dan port yang sama sekali lagi untuk sambungan baharu.

Anda boleh memerhatikan sifat ini dengan mewujudkan berbilang sambungan secara manual kepada hos yang sama. Contohnya, mempunyai pelayan web yang berjalan pada 10.1.1.1 dan port 80, dan menyambung dua kali dengan 10.2.2.2. menggunakan nc:

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

Sambungan ke 10.1.1.1 80 port berjaya!

Semasa sambungan dibuka, anda boleh menggunakan netstat pada klien atau pelayan untuk memaparkan maklumat tentang sambungan ini:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 DITUBUHKAN

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 DITUBUHKAN

Seperti yang anda lihat, pelanggan telah memilih dua port sumber (rawak) yang berbeza, jadi ini tidak melanggar keperluan keunikan utama.

Anda boleh memberitahu nc untuk menggunakan port sumber tertentu dengan pilihan -p:

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

Sambungan ke 10.1.1.1 80 port berjaya!

nc: bind failed: Alamat sudah digunakan

Timbunan TCP/IP pelanggan menghalang keunikan utama daripada dikompromi. Beberapa pelaksanaan tindanan TCP/IP yang jarang berlaku dan buggy tidak mengikut peraturan ini, dan oleh itu, seperti yang akan kita lihat tidak lama lagi, pf akan menyekat sambungan mereka jika keunikan kunci dilanggar.

Mari kita kembali ke tempat pf menanyakan jadual keadaan apabila paket mula ditapis. Permintaan terdiri daripada dua langkah. Pertanyaan pertama dibuat untuk mencari entri dalam entri jadual dengan kunci yang sepadan dengan protokol, alamat dan port paket. Pencarian akan dijalankan untuk paket yang pergi ke mana-mana arah. Mari kita anggap bahawa pakej berikut mencipta entri dalam jadual keadaan:

masukTCPdari 10.2.2.2:28054hingga 10.1.1.1:80

Pertanyaan jadual akan menemui entri berikut dalam jadual keadaan:

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 jadual termasuk maklumat tentang arah (masuk atau keluar) paket pertama yang mencipta entri. Sebagai contoh, entri berikut tidak akan menghasilkan padanan:

keluarTCPdari 10.2.2.2:28054hingga 10.1.1.1:80

masukTCPdari 10.1.1.1:80hingga 10.2.2.2:28054

Sebab sekatan ini tidak jelas, tetapi agak mudah. Bayangkan anda hanya mempunyai satu antara muka dengan alamat 10.1.1.1, di mana pelayan web mendengar pada port 80. Apabila klien 10.2.2.2 menyambung menggunakan port keluar 28054 yang dipilih secara rawak, paket sambungan pertama tiba pada antara muka anda dan semua respons keluar anda sepatutnya akan pergi dari 10.1.1.1:80 ke 10.2.2.2:28054. Anda tidak akan membenarkan paket keluar dari 10.2.2.2:28054 hingga 10.1.1.1:80, kerana paket tersebut tidak bermakna.

Jika tembok api anda dikonfigurasikan untuk dua antara muka, maka dengan memerhatikan paket yang melaluinya, anda akan melihat bahawa setiap paket yang masuk ke antara muka pertama padam dan melalui yang kedua. Jika anda mencipta rekod keadaan di mana paket awal tiba pada antara muka pertama, maka rekod itu akan menghalang paket yang sama daripada meninggalkan antara muka kedua kerana ia tersalah hala.

Apabila percubaan untuk mencari paket antara entri dalam jadual keadaan gagal, senarai peraturan penapis dilalui. Anda mesti secara khusus membenarkan paket itu keluar melalui antara muka kedua dengan peraturan yang berasingan. Anda mungkin menggunakan 'keep state' dalam peraturan ini supaya entri kedua dalam jadual keadaan meliputi keseluruhan sambungan dan pada antara muka kedua.

Anda mungkin tertanya-tanya bagaimana mungkin untuk mencipta rekod kedua dalam jadual jika kami hanya menjelaskan bahawa rekod mesti mempunyai kunci unik. Penjelasan di sini ialah rekod itu juga mengandungi maklumat tentang arah sambungan, dan gabungan ini dengan data yang lain mestilah unik.

Sekarang kita juga akan dapat menerangkan perbezaan antara sambungan percuma dan sambungan terikat antara muka. Secara lalai, pf mencipta entri yang tidak terikat pada mana-mana antara muka. Oleh itu, jika anda membenarkan sambungan pada satu antara muka, paket yang berkaitan dengan sambungan dan sepadan dengan entri jadual (termasuk maklumat tentang arah paket!) melalui mana-mana antara muka. Dalam pemasangan mudah dengan penghalaan statik, ini adalah pengiraan yang lebih teori. Pada dasarnya, anda tidak sepatutnya melihat paket daripada sambungan yang sama tiba pada berbilang antara muka dan paket tindak balas yang meninggalkan berbilang antara muka juga. Walau bagaimanapun, dengan penghalaan dinamik ini adalah mungkin. Anda boleh mengikat rekod keadaan pada antara muka tertentu menggunakan tetapan global 'tetapkan polisi keadaan jika terikat' atau pilihan setiap peraturan 'kekalkan keadaan (jika terikat)'. Dengan cara ini anda akan memastikan bahawa paket hanya akan dipadankan dengan rekod daripada antara muka yang mencipta rekod ini.

Jika antara muka terowong digunakan, maka sambungan yang sama melalui tembok api beberapa kali. Sebagai contoh, paket pertama sambungan mungkin mula-mula melalui antara muka A, kemudian melalui B, kemudian C dan akhirnya meninggalkan kami melalui antara muka D. Biasanya paket akan dikapsulkan pada antara muka A dan D dan dinyahkapsul pada B dan C, jadi pf melihat paket protokol yang berbeza dan anda boleh membuat 4 entri berbeza dalam jadual keadaan. Tanpa enkapsulasi, paket tidak akan berubah pada keempat-empat antara muka dan anda tidak akan dapat menggunakan beberapa ciri, seperti terjemahan alamat atau modulasi nombor jujukan TCP, kerana ini akan menyebabkan kekunci bercanggah muncul dalam jadual keadaan. Sehingga anda mempunyai pemasangan lengkap yang termasuk antara muka dengan ralat terowong dan nyahpepijat seperti "pf: src_tree insert failed", anda tidak akan dapat menganggap pemasangan anda cukup berjaya. Mari kembali ke pertanyaan jadual keadaan yang dibuat untuk setiap paket sebelum menyemak peraturan. Pertanyaan mesti mengembalikan satu rekod dengan kunci yang sepadan, atau tidak mengembalikan apa-apa. Jika pertanyaan tidak mengembalikan apa-apa, senarai peraturan dilalui.

Jika entri ditemui, langkah kedua untuk paket TCP sebelum ia dianggap milik sambungan tertentu dan ditapis adalah untuk menyemak nombor urutan.

Terdapat sejumlah besar serangan TCP di mana penyerang cuba mengawal sambungan antara dua hos. Dalam kebanyakan kes, penyerang tidak berada dalam laluan laluan antara hos, dan oleh itu tidak boleh mencuri dengar pada paket sah yang dihantar oleh hos. Walau bagaimanapun, dia boleh menghantar paket kepada mana-mana hos, mensimulasikan paket teman bicaranya, dengan memalsukan ("spoofing") - memalsukan alamat pengirim. Matlamat penyerang mungkin adalah untuk menghalang sambungan antara hos daripada dibuat, atau untuk menamatkan sambungan yang telah ditetapkan (untuk menyebabkan penafian perkhidmatan), atau untuk mencipta muat turun berniat jahat pada sambungan.

Untuk serangan yang berjaya, penyerang perlu "meneka" dengan betul beberapa parameter sambungan, seperti sumber dan alamat/port destinasi. Dan untuk protokol yang digunakan secara meluas, ini mungkin tidak sesukar yang kelihatan. Jika penyerang mengetahui alamat hos dan salah satu port (kerana kita bercakap tentang perkhidmatan biasa), dia hanya perlu "meneka" satu port. Walaupun pelanggan menggunakan port sumber yang benar-benar rawak (yang tidak selalu benar), penyerang hanya perlu melintasi 65536 port dalam tempoh yang singkat. (Dalam kebanyakan kes, walaupun (65536-1024) port, iaitu hanya port yang tidak mempunyai keistimewaan - nota penterjemah))

Tetapi apa yang benar-benar sukar untuk penyerang meneka ialah nombor urutan yang betul (dan pengesahannya). Jika kedua-dua hos memilih nombor jujukan awal secara rawak (atau anda menggunakan modulasi nombor jujukan untuk hos yang mempunyai penjana ISN (Nombor Urutan Awal) yang lemah), maka penyerang tidak akan dapat mencari nilai yang sesuai pada masa yang sesuai dalam sambungan .

Semasa kewujudan sambungan TCP yang sah, nombor jujukan (dan pengakuan) untuk paket individu berubah mengikut peraturan tertentu.

Sebagai contoh, jika hos menghantar beberapa segmen data dan penerimanya mengakui penerimaan, tidak sepatutnya ada sebab mengapa pengirim perlu menghantar data segmen itu semula. Tetapi, sebenarnya, percubaan untuk menimpa bahagian maklumat yang telah diterima oleh hos bukanlah pelanggaran protokol TCP, walaupun ia mungkin sejenis serangan.

pf menggunakan peraturan untuk menentukan julat terkecil untuk nombor jujukan yang sah. Secara umum, pf boleh menentukan dengan tepat identiti hanya 30,000 daripada 4294967296 nombor jujukan yang mungkin pada bila-bila masa dalam sambungan. Hanya jika nombor urutan dan pengakuan disertakan dalam tetingkap ini, pf akan yakin bahawa paket itu sah dan akan membenarkannya melalui.

Jika entri yang sesuai ditemui semasa pertanyaan ke jadual negeri, langkah seterusnya Nombor jujukan paket yang disimpan dalam jadual disemak untuk melihat sama ada ia berada dalam julat nilai yang mungkin. Jika perbandingan gagal, pf akan menjana mesej "keadaan BAD" dan membuang paket tanpa menilai set peraturan. Terdapat dua sebab mengapa perbandingan dengan peraturan mungkin tidak berlaku: hampir pasti akan menjadi ralat untuk terlepas paket, kerana jika mengira set akan mengakibatkan peraturan memukul pilihan "keep state" dan pf tidak akan dapat membuat keputusan dan mencipta rekod baharu kerana ini akan membawa kepada kekunci bercanggah dalam jadual.

Untuk melihat dan log mesej "keadaan BAD", anda perlu mendayakan mod penyahpepijatan menggunakan arahan:

$ pfctl -xm

Mesej nyahpepijat dihantar ke konsol secara lalai, dan syslogd juga menulisnya ke /var/log/messages. Cari mesej bermula dengan "pf":

pf:TERUKnyatakan:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo=1185380879tinggi=1185380879menang=33304modulator=0wscale=1]

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

dir=out,fwd

pf: Keadaan kegagalan pada: 1 |

Mesej ini sentiasa datang secara berpasangan. Mesej pertama menunjukkan entri jadual keadaan pada masa paket disekat dan nombor urutan paket yang menyebabkan ralat. Entri kedua memaparkan syarat yang dilanggar.

Pada penghujung mesej pertama, anda akan melihat sama ada rekod status telah dibuat untuk paket masuk (dir=in) atau keluar (dir=out), dan sama ada paket yang disekat itu bergerak ke arah yang sama (dir=,fwd ) atau arah bertentangan (dir=,rev) ) arah.

Entri dalam jadual mengandungi tiga alamat: pasangan port, dua daripadanya sentiasa sama antara satu sama lain, jika sambungan tidak mengalami penukaran nat, rdr atau bnat. Untuk sambungan keluar, sumber paket dipaparkan di sebelah kiri dan destinasi paket di sebelah kanan. Jika sambungan keluar melibatkan terjemahan alamat sumber, pasangan di tengah menunjukkan sumber selepas terjemahan. Untuk sambungan masuk, sumber berada di sebelah kanan output dan alamat destinasi berada di tengah. Jika sambungan masuk tertakluk kepada terjemahan alamat destinasi, pasangan ip/port di sebelah kiri menunjukkan destinasi selepas terjemahan telah dilakukan. Format ini sepadan dengan output pfctl -ss, kecuali pfctl menunjukkan arah paket menggunakan anak panah.

Dalam output anda boleh melihat nombor jujukan hos semasa dalam kurungan segi empat sama. Jadi nilai "4:4" bermakna sambungan telah diwujudkan sepenuhnya (nilai yang lebih kecil berkemungkinan besar pada peringkat penubuhan sambungan, nilai yang lebih besar lebih berkemungkinan pada masa sambungan ditutup)."A" bermakna bahawa paket yang disekat mempunyai set bendera ACK (seperti dalam output bendera tcpdump), diikuti dengan nilai nombor urutan (seq=) dan (ack=) dalam paket yang disekat dan panjang muatan paket - panjang data (len =). askskew ialah sebahagian daripada perwakilan dalaman data dalam jadual, digunakan hanya untuk nilai yang tidak sama dengan sifar.

Entri "pkts=930:631" bermakna ia sepadan dengan 940 paket yang bergerak dalam arah yang sama seperti paket yang menyebabkan entri dibuat dan 631 paket dalam arah yang bertentangan. Kaunter ini akan berguna terutamanya dalam menyelesaikan masalah fasa persediaan sambungan jika salah satu daripadanya sama dengan sifar, ini akan bercanggah dengan jangkaan anda bahawa paket yang pergi ke kedua-dua arah sepadan dengan entri yang diberikan.

Mesej berikut akan mengandungi senarai satu atau lebih nombor. Setiap nombor mewakili ujian di mana ralat berlaku:

1. Saiz tetingkap paket melebihi saiz maksimum penerima (seq + len > high)
2. paket mengandungi data yang telah dihantar (seq< lo - win)
3. ackskew adalah kurang daripada nilai minimum
4. ackskew adalah lebih besar daripada nilai maksimum
5. sama seperti dalam (1), tetapi dengan perbezaan (seq + len > tinggi + menang)
6. sama seperti dalam (2), tetapi (seq< lo - maximum win)

Nasib baik, mesej "keadaan BAD" tidak digunakan pada trafik harian sebenar dan menyemak nombor jujukan pf mengelakkan kebanyakan anomali. Jika anda melihat mesej ini muncul secara sporadis dan tidak melihat sejumlah besar sambungan yang tergantung, anda boleh mengabaikannya. Terdapat banyak pelaksanaan TCP/IP yang dijalankan di Internet, dan sesetengah daripadanya kadangkala boleh menjana paket yang salah.

Walau bagaimanapun, kelas masalah ini boleh didiagnosis dengan mudah dengan kemunculan mesej "keadaan BAD" yang muncul hanya dalam kes sedemikian.

Mencipta Rekod NegeriTCP mengikut permulaanSYN ke pakej.

Sebaik-baiknya, rekod keadaan harus dibuat apabila paket SYN pertama berlaku.

Anda boleh memaksa penggunaan peraturan ini menggunakan prinsip:

"Gunakan pilihan "flags S/SA" dalam semua peraturan "pass proto tcp keep state"

Hanya paket SYN awal (dan hanya ini) mempunyai set bendera SYN dan ACK dikumpulkan. Apabila pilihan "keep state" digunakan hanya pada paket SYN awal, hanya paket tersebut akan membuat entri dalam jadual keadaan. Oleh itu, sebarang entri sedia ada dalam jadual keadaan akan diperoleh daripada paket SYN awal.

Sebab untuk mencipta rekod hanya untuk paket awal ialah sambungan protokol TCP yang dipanggil "penskalaan tetingkap" yang ditakrifkan dalam RFC1323. Medan pengepala TCP yang digunakan untuk mengumumkan saiz tetingkap yang diterima adalah terlalu kecil untuk pautan komunikasi berkelajuan tinggi hari ini. Pelaksanaan TCP/IP moden lebih suka menggunakan nilai yang besar saiz tingkap daripada yang boleh dimuatkan dalam kotak sedia ada. Penskalaan saiz tetingkap bermakna semua saiz tetingkap yang diketahui daripada hos penerima mesti didarab dengan nilai tertentu yang ditentukan oleh penerima, bukannya diambil sendiri. Untuk skim ini berfungsi, kedua-dua hos mesti menyokong sambungan dan menunjukkan antara satu sama lain bahawa mereka boleh melaksanakannya semasa fasa jabat tangan menggunakan pilihan TCP. Pilihan ini hanya terdapat dalam paket SYN dan SYN+ACK awal. Hanya jika setiap paket ini mengandungi pilihan, persetujuan bersama akan berjaya dan saiz tetingkap semua paket berikutnya akan didarabkan dengan faktor.

Jika pf "tidak menyedari" penskalaan tetingkap yang digunakan, ia akan mengambil nilai yang dibekalkan tanpa faktor, dan mengira saiz tetingkap untuk nilai nombor jujukan yang boleh diterima adalah salah. Biasanya, hos menyediakan saiz tetingkap kecil pada permulaan sambungan dan meningkatkannya apabila sambungan berjalan. Tidak menyedari kewujudan faktor yang mengubah saiz tetingkap, pf akan pada satu ketika akan mula menyekat paket, kerana ia akan percaya bahawa salah satu hos cuba memintas saiz tetingkap maksimum yang disediakan oleh "interlocutor". Kesan ini mungkin lebih atau kurang ketara. Kadangkala, hos akan bertindak balas terhadap kehilangan paket dengan berpindah ke yang dipanggil. "mod pemulihan kerugian" dan akan mengiklankan saiz tetingkap yang lebih kecil. Selepas pf menghantar semula paket yang digugurkan pada kali pertama, saiz tetingkap akan terus meningkat, ke tahap di mana pf akan mula menyekatnya semula. Manifestasi luaran mungkin sambungan terhenti sementara dan prestasi rendah. Terdapat juga kemungkinan bahawa sambungan mungkin membeku atau menetapkan semula sepenuhnya kerana tamat masa.

Tetapi pf tahu tentang kemungkinan menskalakan tingkap dan menyokong kemungkinan ini. Walau bagaimanapun, prasyarat untuk mencipta entri jadual keadaan pada paket SYN pertama ialah pf boleh mengaitkan dua paket pertama sambungan dengan entri jadual. Dan oleh kerana padanan penuh pekali saiz tetingkap hanya berlaku dalam dua paket pertama ini, tiada kaedah yang boleh dipercayai untuk menentukan pekali ini selepas sambungan dirundingkan.

Pada masa lalu, penskalaan saiz tetingkap tidak digunakan secara meluas, tetapi ini berubah dengan pantas. Baru-baru ini Linux telah mendayakan pilihan ini secara lalai. Jika anda menghadapi kesukaran dengan menggantung sambungan, terutamanya dengan gabungan hos tertentu, dan melihat mesej "keadaan BURUK" yang berkaitan dengan sambungan ini, pastikan anda benar-benar mencipta entri jadual keadaan pada paket pertama sambungan.

Anda boleh menentukan sama ada pf menggunakan pilihan penskalaan untuk sambungan daripada output pfctl:

$ pfctl -vss

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

skala 0skala 1

Jika terdapat entri "wscale x" yang dicetak pada baris kedua (walaupun x adalah sifar), pf akan membaca bahawa ia tahu bahawa sambungan menggunakan penskalaan.

Satu lagi kaedah mudah untuk mengenal pasti masalah yang berkaitan dengan penskalaan adalah untuk melumpuhkan sokongan penskalaan buat sementara waktu dan memainkan semula situasi. Pada OpenBSD, penggunaan penskalaan boleh dikawal oleh pilihan sysctl:

$ sysctljaring.inet.tcp.rfc1323

jaring.inet.tcp.rfc1323=1

$ sysctl -wsysctljaring.inet.tcp.rfc1323=0

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

Masalah yang sama muncul apabila anda membuat entri dalam jadual keadaan untuk paket selain daripada SYN awal dan menggunakan pilihan atau siaran "mulate state". Dalam kedua-dua kes, siaran berlaku pada permulaan sambungan. Jika paket pertama tidak diterjemahkan, tranching paket berikutnya biasanya tidak menggalakkan penghujung penerima dan menyebabkan balasan yang dihantar disekat oleh pf dengan mesej "keadaan BAD".

Bahagian ini dikemas kini setiap hari. Sentiasa versi terkini yang terbaik program percuma untuk kegunaan harian dalam bahagian Program yang diperlukan. Terdapat hampir semua yang anda perlukan untuk kerja harian. Mula meninggalkan versi cetak rompak secara beransur-ansur memihak kepada analog percuma yang lebih mudah dan berfungsi. Jika anda masih tidak menggunakan sembang kami, kami amat mengesyorkan agar anda berkenalan dengannya. Di sana anda akan menemui ramai kawan baru. Di samping itu, ini adalah cara terpantas dan paling berkesan untuk menghubungi pentadbir projek. Bahagian Kemas Kini Antivirus terus berfungsi - sentiasa kemas kini percuma untuk Dr Web dan NOD. Tidak sempat membaca sesuatu? Kandungan penuh ticker boleh didapati di pautan ini.

Firewall percuma Comodo. Ujian, kesimpulan

Comodo Firewall sedang beraksi

Selepas pemasangan dan konfigurasi, Comodo bersembunyi di dalam dulang dan mula mengganggu saya dengan soalannya. Pada hari pertama saya bermain-main dengan semua firewall dan mod perlindungan proaktif dan akhirnya menyenyapkannya. Tiada brek ditemui dalam sistem kami selepas penampilannya. Secara umum, bekerja dengan tembok api dari Comodo agak mudah dan mudah. Antara muka tetingkap utama adalah sangat mudah dan bermaklumat:

Tetapi saya terpaksa membiasakan diri untuk menavigasi melalui tembok api dan tetapan perlindungan proaktif - tidak selalu mungkin untuk mencari item yang betul dengan cepat. Saya fikir ini akan hilang dengan masa.

Beberapa hari selepas memasang Comodo Firewall, saya memutuskan untuk mengujinya sedikit.

Ujian No 1. Ujian dalam talian

Apabila anda mengklik pada butang "Ujian", program ini cuba mewujudkan sambungan dengan pelayan tapak.

Memandangkan Comodo Firewall belum mengetahui utiliti ini, kali pertama ia cuba mengakses Internet, terdapat tindak balas segera daripada perlindungan proaktif dan firewall:

Dalam kedua-dua kes, saya mengklik blok dan menerima pengesahan bahawa ujian itu berjaya:

Kemudian saya menamakan semula fail itu FireWallTest.exe V opera.exe dan menggantikan fail Opera standard dengannya. Oleh itu, saya cuba menipu Comodo Firewall, yang sudah mengetahui penyemak imbas ini dengan baik dan sentiasa dan secara automatik mengeluarkannya ke Internet. Comodo bertindak balas terhadap pelancaran Opera "palsu" daripada Total seperti berikut:

Setelah menerima kebenaran saya untuk pelancaran sekali sahaja, tembok api memberi amaran kepada saya bahawa Opera sedang cuba mengakses Internet:

Ternyata mana-mana aplikasi yang sudah ada peraturan, jika fail boleh laku diganti tanpa pengetahuan saya, tidak akan dapat mengakses Internet. Segala-galanya nampaknya baik-baik saja, tetapi inilah perkaranya: warna bahagian atas tetingkap amaran bergantung pada keterukan keadaan. Jika Comodo menilai sesuatu peristiwa sebagai kritikal, warnanya akan menjadi merah, jika acara itu kurang berbahaya, ia akan menjadi kuning. Dalam kes saya, Comodo menganggap situasi simulasi tidak begitu berbahaya dan menghidupkan lampu "kuning". Selain itu, bukannya perkataan "fail boleh laku opera.exe tidak dikenali" Saya lebih suka melihat bahawa "terdapat perubahan dalam parameter fail opera.exe" Beginilah cara penuai dari Kaspersky dan Eset, sebagai contoh, memberi amaran dalam situasi sedemikian. Lebih-lebih lagi, pengguna melihat tetingkap penggera menggunakan warna merah, yang segera memaksa mereka untuk memberi perhatian kepada keadaan. Dan amaran daripada Comodo boleh diabaikan oleh pengguna kerana penekanan yang tidak mencukupi pada peristiwa yang berlaku.

Menggantikan fail Opera hanyalah sebahagian daripada saya rancangan licik. Mangsa seterusnya ialah Internet Explorer 6, yang disepadukan ke dalam sistem pengendalian, dan, oleh itu, iexplore.exe boleh dianggap sebagai fail sistem sepenuhnya. Bayangkan kejutan saya apabila, di bawah kesunyian Comodo, saya melihat tetingkap tentang kegagalan ujian:

Nampaknya, peraturan tambahan telah dibuat, saya memutuskan dan pergi ke tembok api dan dasar perlindungan proaktif. Selepas membelek-belek di sana selama kira-kira 15 minit, saya membuat satu-satunya keputusan yang tepat - untuk memasang semula Comodo. Tidak lebih awal berkata daripada selesai. Meninggalkan mod pengendalian lalai, saya mengulangi percubaan dengan penggantian iexplore.exe. Apabila dilancarkan daripada Total, perlindungan proaktif berfungsi, seperti dalam kes Opera:

Di sini anda perlu melakukan sedikit penyimpangan lirik. Hakikatnya ialah apabila fail boleh laku IE diganti, sistem memulihkan fail asal dalam masa 4-8 saat iexplore.exe. Dalam hal ini, keputusan ujian saya bergantung kepada sama ada fail palsu itu berjaya sampai ke Internet atau tidak.

Dalam kes apabila saya berjaya menyelesaikan semua manipulasi sebelum memulihkan explore.exe, perkara berikut berlaku. Setelah mendapat kebenaran saya untuk pelancaran sekali sahaja explore.exe, Total melancarkan utiliti FireWallTest, tekan "Uji", perlindungan proaktif Defens+ mengeluarkan amaran:

Jika kami membenarkannya (sebagai percubaan), tembok api berfungsi:

Kami berjaya mengklik "Sekat" - ujian telah diluluskan, utiliti tidak sampai ke Internet. Tetapi kalau iexplore.exe dipulihkan sebelum anda menekan butang blok - tiada apa yang bergantung pada pilihan anda - utiliti secara automatik mendapat akses Internet pada masa fail asal dipulihkan.

Perkara yang sama berlaku untuk kerja perlindungan proaktif: jika anda tidak mempunyai masa untuk menyekat perintah sebelum pemulihan explore.exe- utiliti secara automatik mendapat akses kepada Internet.

Setelah bermain cukup dengan IE palsu, saya teringat kegagalan pertama ujian, apabila Comodo tetap diam dan mengeluarkan fail "salah" di Internet. Selepas memasang semula Comodo, saya meletakkan Defense+ dan firewall ke dalam mod latihan dan melancarkan IE. Selepas itu, saya mengembalikan mod lalai dan mengulangi ujian. Comodo secara senyap gagal lagi...

Ujian No 3. Duel

Terkesan dengan keputusan ujian sebelumnya, saya mencari peluang tambahan untuk menguji Comodo dan akhirnya menemui utiliti AWFT.

Program ini meniru tingkah laku Trojan dan mengandungi satu siri enam ujian yang ditunjukkan pelbagai teknik akses tanpa kebenaran ke rangkaian, memintas perlindungan firewall. Di antara ujian ini terdapat kedua-dua cara lama untuk menipu tembok api dan teknik yang lebih moden. Untuk setiap ujian yang berjaya lulus, tembok api diberikan sejumlah mata tertentu. Jika ujian tidak lulus, mata akan diberikan kepada AWFT. Bilangan mata maksimum ialah sepuluh.

Utiliti adalah perisian kongsi, terhad kepada 10 pelancaran. Di bahagian atas tetingkap program terdapat butang yang melancarkan ujian yang sepadan di bahagian bawah adalah tapak di mana AWFT akan menembusi, dan hasil pertarungan antara firewall dan utiliti. Butang Set Semula Mata digunakan untuk menetapkan semula mata terkumpul.

Sekiranya berlaku, saya memutuskan untuk menukar alamat tapak kepada saya sendiri.

Ujian berlaku dengan Comodo Firewall dan Defense+ dihidupkan, Opera berjalan dan monitor Avira dimatikan.

Ujian pertama menggunakan teknik memuatkan salinan tersembunyi pelayar dan menampal memori sebelum melancarkannya.

Apabila saya mengklik butang ujian, tetingkap muncul dengan ralat:

Selepas menutup tetingkap ini, Comodo membalas ujian dengan tetingkap permintaan apabila anda mengklik butang "Sekat", AWFT, selepas berfikir sedikit, memberikan titik pertama kepada tembok api.

Menurut pemaju utiliti, ujian No. 2 adalah helah lama dan terkenal. Comodo membalas sekali lagi dengan tetingkap permintaan dan markah sekali lagi.

Ujian #3 juga menggunakan helah lama. Comodo hanya senyap menghalangnya, nampaknya, helah itu benar-benar diketahui.

Ujian No. 4 adalah serupa dengan ujian pertama dengan melancarkan salinan tersembunyi penyemak imbas dan menampal memori sebelum melancarkannya. Firewall tidak memberikan sebarang amaran, tetapi selepas jeda yang singkat ia memperoleh satu lagi mata.

Semasa ujian kelima dan keenam, anda perlu beralih ke penyemak imbas dan melayari sedikit (saya baru menyegarkan halaman yang dimuatkan dalam penyemak imbas).

Dalam ujian No. 5, utiliti melakukan carian heuristik untuk perisian dibenarkan yang dipasang pada komputer (atau rangkaian) yang mempunyai akses kepada Internet melalui port 80, kemudian melancarkan salinan program yang dibenarkan dan, sejurus sebelum pelancaran, menampal memori diduduki oleh program ini (iaitu, AWFT melancarkan dirinya dalam ingatan program yang dibenarkan). Comodo menyelesaikan ujian secara senyap dan menerima 3 mata kekalahan untuknya.

Ujian No. 6 adalah serupa dengan ujian kelima sebelumnya. Teknik yang sama digunakan dengan carian heuristik untuk perisian yang dipasang yang mempunyai hak untuk keluar melalui port 80. Hanya kaedah penggodaman kini telah diubah - permintaan pengguna digunakan. Pada masa yang sama, AWFT cuba melampirkan bar alat kiri tersembunyi pada penyemak imbas. Apabila saya membuka Opera, tetingkap berikut muncul:

Sebaik sahaja saya mengesahkan permintaan pengguna ini, Comodo mengeluarkan permintaannya, utiliti telah disekat sekali lagi dan firewall menerima 3 mata dalam kreditnya.

Keputusan pertarungan ialah 10:0 memihak kepada Comodo. Mengulangi ujian dengan Internet Explorer terbuka, saya mendapat keputusan yang sama.

Kesimpulan

Walaupun beberapa rasa selepas yang buruk dalam hati saya, kekal selepas menguji firewall, saya masih mengesyorkan Comodo Internet Security untuk kegunaan rumah, tetapi hanya sebagai firewall. Dan jangan dengar orang pintar yang menasihati untuk mematikan perlindungan proaktif, dalam apa jua keadaan! Hanya dengan penggunaan Defense+, tembok api ini benar-benar memastikan keselamatan komputer anda. Tetapi perkara yang anda tidak patut gunakan ialah antivirus Comodo. Ia bukan sahaja melangkau sedikit, tetapi anda akan menghadapi masalah mengemas kininya - pangkalan datanya sangat menyusahkan. Di samping itu, ia memberi kesan ketara kepada prestasi sistem. Comodo Firewall dan Avira Antivir Personal berfungsi dengan baik untuk saya.

Saya tidak menemui sebarang brek atau gangguan dalam sistem semasa tembok api sedang berjalan. Saya akan menyimpan pemikiran saya tentang keputusan ujian saya buat masa ini; Saya ingin mendengar komen anda.

Semasa menulis bahagian akhir artikel ini, saya menemui hasil ujian tembok api baru-baru ini oleh makmal Matousec. Comodo Internet Security adalah satu-satunya tembok api dengan skor 100% (lihat forum tembok api). Baiklah, saya membuat pilihan saya... Dan awak?

kelebihan (jelas):
pengedaran percuma,
ketersediaan pangkalan data programnya sendiri;
ketersediaan perlindungan proaktif (Pertahanan+);
kemudahan pemasangan dan persediaan awal;
tetingkap yang sangat bermaklumat dan mudah dengan ringkasan;

kebaikan (ragu-ragu):
kehadiran beberapa mod operasi;

kontra (jelas):
mod pemasangan yang menjengkelkan;
penggantian fail boleh laku tidak dikenal pasti oleh perlindungan proaktif sebagai peristiwa kritikal;

kontra (ragu-ragu):
terus terang antivirus tidak berjaya.

Ujian perbandingan 21 tembok api popular untuk kualiti perlindungan terhadap serangan yang datang dari dalam sistem. Ujian ini menguji perlindungan menggunakan 64 utiliti ujian yang dibangunkan khas yang memeriksa perlindungan proses daripada penamatan, perlindungan daripada serangan dalaman standard, perlindungan daripada kebocoran bukan standard dan perlindungan daripada teknik bukan standard untuk mod kernel menembusi.

Bersama-sama dengan antivirus, firewall adalah salah satu komponen utama keselamatan komputer. Walau bagaimanapun, tidak seperti antivirus, ujian objektif prestasi tembok api jarang dijalankan. Kami cuba menutup jurang ini dengan menjalankan ujian tembok api untuk perlindungan terhadap serangan dalaman pada 2011 dan 2012 dan ujian IDS/IPS peribadi untuk perlindungan daripada serangan pada aplikasi yang terdedah. Tahun ini, kami memutuskan untuk mengembangkan senarai kaedah yang digunakan dan mengulangi ujian tembok api untuk perlindungan daripada serangan dalaman untuk melihat bagaimana keputusan produk popular mengikut kriteria ini telah berubah dari semasa ke semasa.

Apakah tujuan ujian ini atau apakah fungsi yang dilakukan oleh tembok api? Menurut definisi standard Internet [RFC3511] (2003), firewall ialah sistem yang melaksanakan fungsi menapis paket rangkaian mengikut peraturan yang ditetapkan untuk membezakan trafik antara segmen rangkaian. Walau bagaimanapun, dengan kerumitan serangan perisian hasad dan penggodam yang semakin meningkat, tugas tembok api asal telah ditambah dengan modul berfungsi baharu. Hampir mustahil untuk membayangkan tembok api yang lengkap tanpa modul HIPS (peristiwa sistem pemantauan, integriti sistem pemantauan, dll.).

Tugas utama tembok api moden adalah untuk menyekat komunikasi rangkaian yang tidak dibenarkan (selepas ini dirujuk sebagai serangan), dibahagikan kepada dalaman dan luaran. Ini termasuk:

Serangan luaran pada sistem yang dilindungi tembok api:

• dimulakan oleh penggodam;
• dimulakan oleh kod jahat.

• dimulakan oleh aplikasi yang tidak dipercayai (kod berniat jahat);
• dimulakan oleh aplikasi yang aktiviti rangkaiannya dilarang secara jelas oleh peraturan.

Di samping itu, produk yang boleh diklasifikasikan sebagai tembok api peribadi tulen dalam formulasi klasik 2003 telah hampir hilang daripada pasaran. Mereka telah digantikan dengan produk perlindungan yang komprehensif komputer peribadi, yang semestinya termasuk komponen tembok api.

Ujian tembok api untuk perlindungan terhadap serangan luar melibatkan pemeriksaan kualiti perlindungan terhadap serangan yang datang dari dalam sistem. Ujian dijalankan di kawasan berikut:

1. Menyemak perlindungan proses daripada penamatan.
2. Perlindungan terhadap serangan dalaman standard.
3. Menguji perlindungan terhadap kebocoran bukan standard.
4. Menguji perlindungan terhadap teknik bukan standard untuk menembusi mod kernel.

Berbanding dengan ujian sebelumnya, bilangan serangan yang digunakan telah meningkat dengan ketara - daripada 40 kepada 64. Sistem pengendalian, yang mesti dilindungi oleh produk yang diuji, juga telah berubah. Dalam ujian sebelumnya ia adalah Windows XP, dan dalam ujian ini ia adalah Windows 7 x32. Ujian serupa juga dirancang untuk penghujung tahun untuk sistem pengendalian Windows 7 x64.

pengenalan

Ujian itu melibatkan 21 program perlindungan komprehensif yang popular (kelas Keselamatan Internet; jika tiada produk sedemikian dalam barisan, maka tembok api semata-mata dipilih) daripada pelbagai pengeluar Versi produk yang terkini pada tarikh mula ujian (Mei 2013) dan dijalankan pada platform Windows 7 x32 :

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

Sebelum memulakan ujian, persekitaran ujian telah disediakan. Untuk melakukan ini, sistem pengendalian Windows 7 Enterprise SP1 x86 dengan semua kemas kini yang tersedia pada masa itu, serta perisian tambahan yang diperlukan untuk ujian, telah dipasang pada komputer yang bersih.

Ujian telah dijalankan pada dua jenis tetapan: standard yang disyorkan oleh pengilang (tetapan lalai) dan maksimum. Dalam kes pertama, tetapan lalai yang disyorkan oleh pengilang telah digunakan dan semua tindakan yang disyorkan oleh program telah dilakukan.

Dalam kes kedua, sebagai tambahan, semua tetapan yang dilumpuhkan dalam mod "lalai", tetapi masih boleh menjejaskan hasil ujian, telah dihidupkan dan/atau dibawa ke kedudukan maksimumnya (tetapan yang paling ketat). Dalam erti kata lain, menetapkan tetapan maksimum bermakna memindahkan semua tetapan yang tersedia daripada antara muka pengguna grafik semua modul yang berkaitan dengan mengesan fail berniat jahat atau aktiviti rangkaian kepada pilihan yang paling ketat.

Ujian tembok api telah dijalankan menggunakan kepada kumpulan berikut serangan dalaman, dibahagikan kepada tahap kesukaran untuk kejelasan:

1. Tahap kesukaran asas (56 pilihan serangan):

1. menyemak perlindungan proses daripada penamatan (41 pilihan serangan);
2. perlindungan terhadap serangan dalaman standard (15 pilihan serangan).

2. Tahap kesukaran meningkat (8 pilihan serangan):

1. menguji perlindungan terhadap kebocoran bukan standard (3 pilihan serangan);
2. menguji perlindungan terhadap teknik bukan standard untuk menembusi mod kernel (5 pilihan serangan).

Penerangan terperinci tentang semua kaedah serangan yang digunakan dalam ujian boleh didapati dalam metodologi ujian.

Memeriksa tembok api untuk perlindungan terhadap serangan dalaman

Biar kami ingatkan anda bahawa mengikut skema anugerah yang digunakan, 1 mata (+) diberikan jika serangan disekat secara automatik dan kefungsian perlindungan program yang diuji tidak rosak. 0.5 mata (atau +/-) - jika serangan disekat hanya dalam keadaan khas (contohnya, apabila pengguna memilih dengan betul tindakan yang diperlukan atas permintaan program yang sedang diuji). Dan akhirnya, jika serangan itu berjaya secara keseluruhan atau sebahagian dan melumpuhkan fungsi perlindungan, maka tiada mata diberikan. Jumlah mata maksimum yang mungkin dijaringkan dalam ujian ini ialah 64.

Jadual 1-2 dan Rajah 1-2 menunjukkan keputusan ujian tembok api secara berasingan pada tetapan standard dan maksimum. Untuk kejelasan, keputusan untuk setiap tembok api dibahagikan kepada dua kumpulan: perlindungan terhadap serangan peringkat asas kerumitan dan perlindungan terhadap serangan dengan tahap kerumitan yang meningkat.

Jadual 1: Keputusan ujian Firewall untuk standardAtetapan rt

Produk yang Diuji							Jumlah mata (maks. 64)	Jumlah %
	mata	%	% daripada jumlah	mata	%	% daripada jumlah
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Perisai dalam talian	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 luar	45	80%	70,3%	2,5	31%	3,9%	47,5	74%
Trend Micro	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%
TrustPort	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%
Bitdefender	41	73%	64,1%	1	13%	1,6%	42	66%
AVG	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
Alatan 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-Secure	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%

Rajah 1: Keputusan ujian Firewall pada tetapan standard

Perlindungan terhadap serangan dalaman pada tetapan yang disyorkan oleh pengilang meninggalkan banyak perkara yang diingini. Hanya tiga firewall dapat mengatasi ambang 80% pada tetapan standard - Comodo, Online Armor dan Norton. Produk Jetico (79%) dan Outpost (74%) agak hampir dengan mereka. Keputusan firewall lain adalah lebih teruk.

Berbanding dengan keputusan ujian terakhir, semua pemimpin mengesahkan keputusan tinggi mereka; hanya terdapat pergerakan kecil dalam kumpulan utama, contohnya, Outpost dan Jetico bertukar kedudukan. Satu-satunya kejutan adalah produk Norton, yang dalam ujian sebelumnya menunjukkan keputusan 45% dan berada di bahagian bawah jadual, dan dalam ujian ini dengan 80% ia mengambil kedudukan ketiga.

Keputusan yang diperoleh adalah disebabkan oleh fakta bahawa banyak pengeluar menetapkan tetapan standard sedemikian rupa untuk mengurangkan bilangan mesej yang pengguna mesti bertindak balas. Ini disahkan oleh keputusan ujian - pada tetapan standard, firewall bertanya soalan kepada pengguna hanya dalam 5.4% serangan, dan pada tetapan maksimum - dalam 9.2% serangan. Walau bagaimanapun, ini menjejaskan kualiti perlindungan, yang akan kekal senyap dalam keadaan di mana program berniat jahat meniru/melakukan tindakan yang benar-benar sah dalam sistem.

Anda juga harus memberi perhatian kepada dua corak. Pertama, peratusan pencegahan jenis serangan yang kompleks secara amnya lebih teruk daripada serangan pada tahap kerumitan asas. Lebih separuh daripada serangan ini ditolak oleh hanya empat produk - Comodo, Online Armor, Norton dan Jetico. Empat lagi produk dimasukkan dalam kumpulan sempadan, menolak daripada 25% kepada 38% daripada serangan tersebut: Outpost, Trend Micro, Kaspersky dan Dr.Web. Semua produk lain menolak tidak lebih daripada satu serangan kompleks. Kedua, prestasi menangkis serangan asas telah bertambah baik. Jika dalam ujian sebelumnya 11 (50%) produk menolak kurang daripada 50% serangan, maka dalam ujian ini hanya terdapat 3 (14%) produk tersebut.

Jadual 2: Keputusan ujian Firewall pada tetapan maksimum

Produk yang Diuji	Serangan kesukaran asas (maks. 56 mata)			Serangan dengan tahap kesukaran yang lebih tinggi (maks. 8 mata)			Jumlah mata(maks. 64)	Jumlah %
	mata	%	% daripada jumlah	mata	%	% daripada jumlah
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Perisai dalam talian	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%
Alatan PC	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Pos luar	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%
Trend Micro	43	77%	67,2%	3	38%	4,7%	46	72%
TrustPort	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%
AVG	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-Secure	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%

Rajah 2: Keputusan ujian Firewall pada tetapan maksimum

Apabila tetapan maksimum didayakan, kualiti perlindungan terhadap serangan dalaman dalam banyak tembok api yang diuji bertambah baik dengan ketara. Ini amat ketara di kalangan petani pertengahan yang kuat. Kesemua ketua ujian sebelum ini juga menunjukkan keputusan yang tinggi dalam ujian ini. Di antara perubahan, perlu diperhatikan produk Bitdefender, yang, bersama dengan Comodo, menunjukkan hasil 100%, dan produk Norton, yang berpindah ke kumpulan terkemuka.

Keputusan beberapa produk pada tetapan standard dan maksimum adalah sama. Ini disebabkan oleh fakta bahawa produk ini tidak mempunyai tetapan yang boleh menjejaskan keputusan ujian kami.

Perbandingan kualiti perlindungan pada tetapan standard dan maksimum

Disebabkan oleh logik ujian ini, kami tidak akan menjumlahkan atau purata keputusan produk yang sama dengan tetapan yang berbeza. Sebaliknya, kami ingin membandingkannya dan menunjukkan perbezaan ketara dalam kualiti perlindungan produk yang diuji bergantung pada tetapan yang digunakan.

Untuk kejelasan, kami membentangkan keputusan akhir ujian tembok api dengan tetapan standard dan maksimum dalam Jadual 3 dan Rajah 3.

Jadual 3: Keputusan ringkasan ujian tembok api pada tetapan standard dan maksimum

produk	Tetapan standard	Tetapan maksimum
Comodo	92%	100%
Perisai dalam talian	90%	95%
Norton	80%	91%
Jetico	79%	79%
Pos luar	74%	85%
Trend Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G DATA	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
Alatan PC	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Rajah 3: Keputusan ringkasan ujian tembok api pada tetapan standard dan maksimum

Rajah 3 menunjukkan dengan jelas perbezaan keputusan ujian bergantung pada tetapan yang dipilih.

Pertama, hanya dua produk - Comodo dan Perisai Dalam Talian - menunjukkan penunjuk perlindungan hampir kepada maksimum, kedua-duanya pada tetapan standard dan maksimum.

Kedua, apabila menukar tetapan standard yang dicadangkan oleh pengilang, sesetengah produk menunjukkan tahap perlindungan yang jauh lebih baik. Ini paling jelas kelihatan dalam produk seperti Bitdefender, Kaspersky, Eset, F-Secure dan Alat PC.

Ketiga, seperti yang dinyatakan di atas, sesetengah produk yang diuji tidak mempunyai tetapan sama sekali yang boleh menjejaskan keputusan ujian dalam apa jua cara. Oleh itu, keputusan mereka untuk semua jenis tetapan dalam ujian ini adalah sama. Kumpulan ini termasuk Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft dan Microsoft.

Skor akhir tidak mengambil kira situasi di mana serangan itu ditangkis, tetapi terdapat masalah dengan antara muka pengguna produk. Dalam kebanyakan kes, masalah terdiri daripada antara muka terhempas untuk masa yang singkat (dari 2 hingga 10 saat) atau sehingga but seterusnya sistem pengendalian. Walaupun produk terus memberikan perlindungan untuk isu antara muka pengguna, kehadiran isu tersebut secara subjektif dianggap sebagai negatif dan boleh mempengaruhi pilihan pemilihan produk. Bilangan masalah dengan antara muka pengguna dibentangkan dalam Jadual 3 dan Rajah 3. Ralat yang timbul daripada serangan tahap 1 telah dinilai, jumlahnya ialah 41.

Jadual 4: Bilangan masalah antara muka pengguna pada tetapan standard dan maksimum

Produk yang Diuji	Tetapan standard		Tetapan maksimum
	Bilangan kesilapan	%	Bilangan kesilapan	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	20	49%	20	49%
F-Secure	19	46%	19	46%
Panda	17	41%	17	41%
Jetico	16	39%	16	39%
Alatan PC	13	32%	13	32%
Trend Micro	12	29%	12	29%
AVG	10	24%	9	22%
TrustPort	9	22%	9	22%
G DATA	9	22%	9	22%
Bitdefender	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Pos luar	5	12%	5	12%
Eset	5	12%	4	10%
Comodo	5	12%	0	0%
Avira	2	5%	2	5%
Dr.Web	2	5%	2	5%
Kaspersky	1	2%	1	2%
Perisai dalam talian	1	2%	1	2%

Rajah 4: Bilangan masalah UI pada tetapan standard dan maksimum

Keputusan menunjukkan bahawa produk McAfee dan Microsoft mengalami masalah antara muka pengguna dalam kebanyakan serangan (lebih daripada 80%). Ini boleh dipanggil tahap yang tidak boleh diterima, kerana... Hampir setiap serangan yang berjaya ditangkis akan membawa kepada masalah. Keputusan yang agak buruk, antara 30% hingga 50%, ditunjukkan oleh produk daripada Kingsoft, F-Secure, Panda, Jetico dan Alat PC. Apabila menggunakannya, setiap 2-3 serangan akan membawa kepada masalah dengan antara muka. Sebilangan produk lain menunjukkan hasil dari 10% hingga 30%, yang boleh dipanggil memuaskan. Keputusan baik menunjukkan produk Avira, Dr.Web, Kaspersky dan Online Armor, masalah yang berlaku dalam julat dari 2% hingga 5% daripada serangan. Satu-satunya produk yang tidak pernah mengalami sebarang masalah dengan antara muka pengguna ialah Comodo pada tetapan maksimum, yang boleh diterima masuk keputusan cemerlang. Walau bagaimanapun, dengan tetapan standard, hasil Comodo merosot (12%), yang menunjukkan bahawa menggunakan produk ini memerlukan sedikit pengetahuan tentang cara mengkonfigurasinya.

Keputusan ujian akhir dan anugerah

Sama seperti dalam ujian sebelumnya, kami tidak meratakan keputusan produk yang sama dengan tetapan yang berbeza, tetapi menganggapnya secara berasingan antara satu sama lain. Oleh itu, setiap produk yang diuji boleh menerima dua anugerah, satu untuk setiap jenis tetapan.

Selaras dengan skim anugerah, tembok api terbaik menerima anugerah yang menunjukkan tetapan yang digunakan, lihat Jadual 4.

Jadual 5: Keputusan akhir ujian tembok api pada tetapan standard dan maksimum

Produk sedang diuji	Pilihan tetapan	Pencegahan Serangan [%]		Jumlah [%]	Ganjaran
		Pangkalan tahap kesukaran	Peningkatan tahap kesukaran
Comodo	Maks	100%	100%	100%	Platinum Firewall Keluar Anugerah Perlindungan
Bitdefender	Maks	100%	100%	100%
Perisai dalam talian	Maks	95%	100%	95%	Tembok Api Emas Keluar Anugerah Perlindungan
Kaspersky	Maks	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Maks	90%	100%	91%
Perisai dalam talian	Standard	89%	94%	90%
Alatan PC	Maks	88%	69%	86%
Pos luar	Maks	88%	69%	85%
Eset	Maks	88%	69%	85%
Norton	Standard	80%	75%	80%
Dr.Web	Maks	83%	63%	80%
Jetico	Maks	82%	56%	79%	Tembok Api Perak Keluar Anugerah Perlindungan
Jetico	Standard	82%	56%	79%
Pos luar	Standard	80%	31%	74%
Trend Micro	Maks	77%	38%	72%
TrustPort	Maks	77%	31%	71%
Trend Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G DATA	Maks	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Tembok Api Gangsa Keluar Anugerah Perlindungan
Avira	Maks	74%	25%	68%
G DATA	Standard	75%	13%	67%
Avast	Maks	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Maks	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Maks	73%	0%	64%
McAfee	Standard	73%	0%	64%
Alatan PC	Standard	73%	0%	64%
Microsoft	Maks	71%	0%	63%
Microsoft	Standard	71%	0%	63%
Avira	Standard	71%	0%	63%
F-Secure	Maks	56%	13%	51%	Tiada pahala
F-Secure	Standard	56%	13%	51%
Panda	Maks	54%	0%	47%
Panda	Standard	54%	0%	47%
Kingsoft	Maks	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

Keputusan terbaik dalam ujian ditunjukkan oleh tembok api Comodo dan Bitdefender, yang mendapat markah 100% pada tetapan maksimum. Kedua-dua produk ini memenangi anugerah PlatinumFirewallKeluarPerlindunganAnugerah.

Keputusan yang sangat tinggi dalam ujian (lebih 80%) juga ditunjukkan oleh tembok api Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset dan Dr.Web, yang menerima anugerah emasFirewallKeluarPerlindunganAnugerah. Adalah penting untuk ambil perhatian bahawa Comodo menerima anugerah ini pada tetapan standard, Perisai Dalam Talian dan Norton pada tetapan standard dan maksimum, dan semua yang lain hanya pada tetapan maksimum.

Seterusnya dalam senarai ialah sekumpulan tujuh tembok api yang hasilnya jatuh dalam julat 60% hingga 70%. Ini ialah Outpost, Kaspersky dan Dr.Web dengan tetapan standard; TrustPort dan G DATA pada tetapan maksimum, serta Jetico dan Trend Micro pada kedua-dua tetapan standard dan maksimum. Mereka semua mendapat pahala

Cukup kumpulan besar Produk yang berada dalam julat 60% hingga 70% menerima anugerah. Perlu diingatkan bahawa produk Eset dan Bitdefender pada tetapan standard dapat menangkis bilangan serangan yang jauh lebih besar pada tetapan maksimum.

Anda boleh melihat keputusan ujian terperinci dan memastikan bahawa pengiraan akhir adalah betul dengan memuat turun keputusan ujian dalam format Microsoft Excel.

Shabanov Ilya, rakan kongsi pengurusan tapak:

“Saya sangat gembira dengan fakta bahawa banyak pengeluar telah meningkatkan perlindungan proaktif dengan ketara terhadap serangan dalaman dan pertahanan diri dalam produk mereka. Kami juga terpaksa menyemak semula skim anugerah untuk meningkatkan tahap keperluan. Skor kurang daripada 51% kini dianggap sebagai kegagalan sepenuhnya.

Saya sangat terkejut kerana Bitdefender menangkis semua 100% serangan dalam mod paranoid, Eset dan Dr.Web dengan keputusan pada tetapan maksimum 85% hingga 80%, masing-masing, serta pendatang baru dalam ujian kami, TrustPort. DALAM " kumpulan emas Menurut keputusan ujian ini, produk termasuk tembok api Comodo, Norton dan Perisai Dalam Talian, yang mendapat markah lebih daripada 80% pada tetapan standard dan maksimum. Keputusan tinggi secara konsisten dalam ujian yang melibatkan perlindungan proaktif ditunjukkan oleh Kaspersky, Outpost dan Alat PC.

Walau bagaimanapun, dalam kes beberapa produk yang diuji, logik untuk menetapkan tetapan standard adalah tidak jelas. Akibatnya, tahap perlindungan untuk kebanyakan pengguna yang biasa menggunakan perlindungan dengan tetapan standard ternyata jauh lebih rendah. Ini terutamanya terpakai kepada produk daripada Bitdefender, Kaspersky, Eset dan Alat PC.”

Mikhail Kartavenko, ketua laman web makmal ujian:

“Memandangkan ujian ini sebagai kesinambungan daripada ujian serupa sebelum ini, kami boleh mengenal pasti beberapa trend dan masalah utama dalam pengendalian tembok api.

Pertama, secara purata, kebanyakan produk menunjukkan hasil yang lebih baik daripada 1.5 tahun yang lalu, tetapi mereka melakukan ini terutamanya dengan menangkis serangan tahap 1 yang paling mudah. Serangan yang lebih kompleks adalah sukar pada rangkaian produk yang terhad sahaja.

Kedua, walaupun perlindungan proses daripada penamatan (peringkat serangan pertama) berfungsi, antara muka pengguna banyak produk ranap. Ini meletakkan pengguna dalam kedudukan janggal di mana dia tidak faham sama ada perlindungan itu berfungsi atau tidak.

Ketiga, terdapat jurang yang agak besar dalam prestasi tembok api pada tetapan standard dan maksimum. Akibatnya, tahap perlindungan yang boleh diterima selalunya hanya boleh diperoleh oleh pengguna berpengalaman yang tahu dan boleh mengkonfigurasi tembok api dengan betul.

Oleh itu, ujian mengenal pasti titik kesakitan tembok api moden, penyelesaian yang boleh meningkatkan perlindungan mereka."