Debugging iptables dan jebakan firewall yang umum?

Kesalahpahaman yang umum terjadi adalah karena wadah buruh pelabuhan atau tamu KVM dijalankan secara lokal, aturan filter yang berlaku harus berada di rantai INPUT, tetapi biasanya tidak demikian.

6. Modul kernel

Karena filter paket berjalan di dalam kernel Linux, ia juga dapat dikompilasi sebagai modul dinamis, sebenarnya beberapa modul. Sebagian besar distribusi menyertakan netfilter sebagai modul dan modul netfilter yang diperlukan akan dimuat ke dalam kernel sesuai kebutuhan, tetapi untuk beberapa modul, administrator firewall perlu memastikannya dimuat secara manual. Ini terutama menyangkut modul pelacakan koneksi, seperti nf_conntrack_ftp yang dapat dimuat dengan insmod .

Modul yang saat ini dimuat ke dalam kernel yang sedang berjalan dapat ditampilkan dengan lsmod .

Metode untuk memastikan modul dimuat secara terus-menerus selama reboot bergantung pada distribusi Linux.

Solusi 2:

Iptables/Firewall "pengenalan"

Firewall pada dasarnya adalah filter jaringan berbasis kebijakan. Firewall Linux dibangun di sekitar Netfilter; kerangka pemrosesan paket jaringan kernel yang terbuat dari beberapa modul kernel yang menjalankan tugas tertentu:

1. Modul FILTER (selalu dimuat secara default) terutama memungkinkan kita untuk MENERIMA atau MENGHAPUS paket IP berdasarkan kriteria pencocokan tertentu.
2. Set modul NAT memungkinkan kita melakukan Terjemahan Alamat Jaringan (SNAT, DNAT, MASQUERADE).
3. Modul MANGLE memungkinkan kita mengubah bidang paket IP tertentu (TOS, TTL).

Pengguna mengonfigurasi kerangka kerja Netfilter agar sesuai dengan kebutuhan firewall mereka menggunakan iptables dari baris perintah. Dengan iptables kami mendefinisikan aturan yang menginstruksikan kernel apa yang harus dilakukan dengan paket IP ketika mereka tiba, melewati, atau meninggalkan kotak Linux kami. Setiap proses utama Netfilter diwakili oleh TABLE (FILTER, NAT, MANGLE) pada istilah iptables. Mereka memiliki beberapa titik kait khusus pada peta aliran paket jaringan di mana mereka dipanggil oleh kernel untuk melakukan tugasnya. Urutan tertentu dari panggilan TABLE secara umum disebut RANTAI bawaan yang menerima nama PREROUTING, INPUT, FORWARD, OUTPUT, dan POSTROUTING. Mudah untuk diingat jika kita mengaitkan TABEL dengan "jenis proses" dan RANTAI dengan "lokasi" pada peta aliran paket jaringan tempat instance dari proses tersebut dipanggil.

Karena paket IP diterima pada antarmuka jaringan, atau dibuat oleh proses lokal, hingga akhirnya dikirimkan atau dibuang, mesin Netfilter akan menguji secara berurutan dan menerapkan aturan yang terdapat di sepanjang peta aliran paket jaringan. Pada setiap blok yang diidentifikasi oleh pasangan [email protected], pengguna dapat menambahkan satu atau lebih aturan berturut-turut yang berisi kriteria pencocokan paket IP dan tindakan yang sesuai. Ada tindakan (mis. ACCEPT, DROP, dll.) yang dapat dilakukan oleh lebih dari satu TABLE dan tindakan lain (mis. SNAT, DNAT, dll.) yang khusus untuk TABLE.

yaitu ketika sebuah paket IP tiba dari antarmuka jaringan, pertama-tama diproses oleh rantai PREROUTING yang meminta aturan yang ditentukan pengguna tabel MANGLE jika ada. Jika tidak ada aturan yang cocok dengan paket saat ini, tindakan atau "kebijakan" default [email protected] yang sesuai berlaku. Pada titik ini jika paket tidak dijatuhkan, proses akan berlanjut sekarang dengan memanggil aturan tabel NAT di rantai PREROUTING (lihat peta) dan seterusnya. Untuk memfasilitasi tata letak aturan, pengguna juga dapat membuat rantai kustom mereka sendiri dan "melompat" ke dalamnya dari berbagai titik di peta sesuai keinginan.

Meskipun rantai bawaan dapat memiliki kebijakan yang ditentukan pengguna untuk paket ACCEPT atau DROP, rantai yang ditentukan pengguna selalu memiliki kebijakan default RETURN yang tidak dapat diubah kepada penelepon untuk melanjutkan proses.

Perintah Iptables

Perintah utama iptables mengisi peta aliran paket jaringan dengan aturan pemrosesan yang diperlukan.

Aturan iptables generik dapat ditulis sebagai:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Itu bisa dibaca seperti:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Perintah tambahan iptables melengkapi skenario pengaturan kondisi default, aturan daftar, aturan pembilasan, dll.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables memuat perintah kami ke mesin Netfilter saat runtime, Netfilter segera memberlakukan aturan dan pengaturan yang dimuat tetapi tidak tetap. Setelah reboot, semua aturan dan pengaturan Netfilter yang dimuat sebelumnya akan hilang. Untuk alasan ini ada utilitas iptables yang memungkinkan untuk menyimpan kumpulan aturan yang sedang aktif ke file dan memuatnya kembali nanti.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Ringkasan Iptables

Netfilter adalah kerangka kerja yang sangat fleksibel dan kuat tetapi ada harga yang harus dibayar untuk itu; Iptables itu kompleks. Dari sudut pandang pengguna, istilah-istilah tertentu seperti TABEL, RANTAI, TARGET tidak terlalu cocok dengan konsep yang mereka wakili dan pada awalnya tidak masuk akal. Topiknya panjang, perintah tampaknya memiliki daftar parameter yang tak ada habisnya. Lebih buruk lagi, tidak ada satu buku pun yang benar-benar menguasai Iptables. Mereka sebagian besar terbagi dalam dua kategori:"buku resep" atau "buku halaman". Saya pikir pengantar ini memberi Anda gambaran tentang lanskap Netfilter/Iptables ditambah dosis yang diperlukan dari halaman manual yang telah dicerna sebelumnya. Jika Anda baru di iptables, setelah membaca paragraf ini beberapa kali Anda akan siap untuk membaca contoh iptables. Dengan beberapa latihan, Anda akan segera menemukan diri Anda menulis aturan Anda sendiri.

Firewall

Firewall terutama dirancang untuk secara dinamis mengizinkan atau menolak lalu lintas jaringan berdasarkan seperangkat aturan. Pada titik ini mudah untuk memahami mengapa kerangka Linux Netfilter/Iptables sempurna untuk konstruksi firewall. Melihat peta aliran paket jaringan, kami menemukan dua tempat yang sangat menarik pada tabel FILTER di rantai INPUT dan FORWARD; Kita dapat memutuskan di sana atas alamat sumber IP, protokol IP (UDP/TCP), port tujuan (80, 21, 443, dll), dll, jika kita MENERIMA, MENOLAK, atau hanya DROP paket IP tertentu. Inilah yang dilakukan firewall 80% dari waktu yaitu melindungi server web dari permintaan jaringan yang tidak sah. 20% sisanya adalah memanipulasi paket jaringan (NAT, MANGLE).

Skenario Firewall

Ada ratusan tata letak firewall berbeda yang memenuhi kebutuhan berbeda, tetapi 3 di antaranya dapat dianggap sebagai skenario firewall yang paling umum.

1. Server web sederhana dengan satu atau beberapa antarmuka yang terhubung ke Internet. Kebijakan mencakup aturan dasar untuk mengizinkan akses masuk yang dibatasi, akses keluar yang tidak dibatasi, dan aturan anti spoofing. Penerusan IP tidak aktif.
2. Firewall ini terhubung ke Internet dan ke area internal yang dilindungi. Kebijakan mencakup aturan dasar untuk mengizinkan akses masuk yang dibatasi, akses keluar yang tidak dibatasi, dan aturan anti spoofing. Karena kawasan lindung menggunakan alamat IP pribadi, sumber NAT diperlukan. Penerusan IP aktif.
3. Firewall ini terhubung ke Internet, area terlindung dan demiliterisasi internal. Kebijakan mencakup aturan dasar untuk mengizinkan akses masuk yang dibatasi, akses keluar yang tidak dibatasi, dan aturan anti spoofing. Karena area yang dilindungi dan DMZ menggunakan alamat IP pribadi, mereka memerlukan NAT sumber dan tujuan. Penerusan IP aktif.

Saya telah menulis ini untuk:http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html

Solusi 3:

Masalah umum dengan protokol yang berbeda

DNS: DNS menggunakan port 53 UDP secara default, tetapi pesan yang tidak muat dalam satu datagram UDP akan dikirim menggunakan TCP sebagai gantinya (biasanya transfer zona dan semacamnya) membutuhkan port 53 TCP untuk dibuka juga saat Anda menjalankan server nama.

Email: Banyak ISP konsumen memblokir lalu lintas SMTP (atau setidaknya port default TCP 25), sehingga tidak mungkin untuk langsung menerima atau mengirim email dan pelanggan mereka terpaksa menggunakan relai SMTP ISP untuk semua email keluar dan terkadang juga untuk email masuk. Terkait dengan §1.1.

FTP: FTP adalah protokol yang aneh dalam hal dua sambungan digunakan. Yang pertama adalah koneksi kontrol, secara default server FTP akan mendengarkan TCP port 21 untuk itu. Koneksi kontrol digunakan untuk otentikasi dan mengeluarkan perintah. Transfer file yang sebenarnya dan hal-hal seperti output dari daftar direktori melewati koneksi TCP kedua, koneksi DATA . Dalam FTP aktif, koneksi DATA akan dimulai dari server FTP dari port TCP 20 dan terhubung ke klien FTP. FTP aktif tidak berfungsi dengan baik dengan pengguna di belakang firewall dan gateway NAT sehingga sebagian besar tidak digunakan lagi. Sebagian besar server FTP support FTP Pasif sebagai gantinya. Dengan FTP Pasif, server FTP membuka pendengar untuk koneksi DATA pada port kedua, yang kemudian dapat dihubungkan oleh klien FTP. Masalah untuk firewall adalah bahwa port DATA dapat berupa port unprivilged yang tersedia antara 1024-65536.

Dalam firewall tanpa kewarganegaraan yang biasanya diselesaikan dengan membatasi jumlah port pasif yang dapat ditetapkan oleh server FTP dan kemudian secara eksplisit membuka port tersebut. yaitu

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

Dalam stateful firewall Anda tidak perlu membuka port DATA secara eksplisit, modul pembantu netfilter akan mengenali port dinamis yang ditugaskan dan secara dinamis membuka port tersebut untuk klien yang benar dengan menandai koneksi DATA sebagai RELATED setelah itu akan cocok dengan aturan umum:

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Ini membutuhkan modul kernel yang benar dimuat, dalam kasus FTP secara manual dengan menjalankan misalnya insmod nf_conntrack_ftp , membuat ketergantungan yang persisten di seluruh reboot tergantung pada distribusi.

Catatan: Modul pelacakan koneksi FTP akan gagal saat FTP digunakan dengan SSL, karena koneksi kontrol akan dienkripsi dan nf_conntrack_ftp tidak akan dapat lagi membaca respons PASV.

NFS dan layanan RPC serupa: Masalah dengan layanan RPC adalah secara desain mereka tidak menggunakan port tetap tertentu. Mereka dapat memilih port yang tersedia secara acak, yang kemudian akan didaftarkan dengan daemon RPC Portmap. Klien yang mencoba terhubung akan meminta daemon Portmap dan kemudian terhubung langsung ke port yang benar. Itu memecahkan masalah kehabisan port yang dicadangkan...

Dari perspektif firewall, port TCP/UDP 111 perlu dibuka dan dan port aktual yang saat ini digunakan oleh layanan RPC. Masalah pembukaan port acak semacam itu di firewall biasanya diselesaikan dengan membatasi layanan RPC, seperti NFS server, untuk menggunakan port tetap yang ditentukan sebelumnya.