Debugger untuk Iptables

47

Saya mencari cara mudah untuk mengikuti paket melalui aturan iptables. Ini bukan tentang logging, karena saya tidak ingin mencatat semua lalu lintas (dan saya hanya ingin memiliki target LOG untuk aturan yang sangat sedikit).

Sesuatu seperti Wireshark untuk Iptables. Atau mungkin bahkan sesuatu yang mirip dengan debugger untuk bahasa pemrograman.

Terimakasih Chris

Catatan: Itu tidak harus menjadi alat GUI mewah. Tapi itu harus melakukan lebih dari sekedar menunjukkan penghitung paket atau lebih.

Pembaruan: Sepertinya kita tidak dapat menemukan apa pun yang menyediakan fungsionalitas yang diminta. Dalam hal ini: Mari kita setidaknya menemukan teknik yang baik yang didasarkan pada iptables logging - yang dapat dengan mudah dinyalakan dan dimatikan, dan tidak perlu menulis aturan iptables secara berlebihan (harus menulis aturan yang sama untuk -j LOGdan -j ...)

ip iptables debugging packet-analyzer Chris Lercher
sumber

Jawaban:

10

Saya tidak bisa memikirkan solusi langsung, tetapi saya bisa memikirkan cara melacak paket.

  1. Catat setiap aturan dengan arahan awalan log (--log-prefix "Rule 34")
  2. Hasilkan paket uji atau aliran paket dengan scapy dan setel bidang TOS ke sesuatu yang unik
  3. ambil output file log untuk pengaturan TOS itu dan lihat aturan mana yang mencatatnya.
Haakon
sumber
Terima kasih untuk idenya. Sayangnya, saya tidak dapat mencatat setiap aturan (Pada satu sistem, disk mungkin tidak akan cukup cepat untuk melakukan itu. Di lain, iptables logging tidak tersedia di kernel.)
Chris Lercher
1
Gunakan pipa bernama sebagai file softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Namun karena Anda tidak dapat masuk ke kernel, Anda agak SOL
Haakon
Terima kasih, ini mungkin tidak akan menyelesaikan masalah saya, tetapi umumnya senang mengetahui, bahwa syslog perpipaan akan dimungkinkan - mungkin berguna di lain waktu!
Chris Lercher
Satu pertanyaan terkait tentang pencatatan: Apakah iptables menangani beberapa paket secara bersamaan (sehingga entri log dapat disisipkan)? Dalam hal itu, saya pikir ide TOS akan menjadi keharusan mutlak bagi banyak analisis LOG iptables!
Chris Lercher
Saya tidak tahu jawabannya. Saya berharap bahwa setiap antarmuka akan ditangani secara bersamaan oleh iptables minimal.
Haakon
82

Jika Anda memiliki kernel dan versi iptables yang cukup baru, Anda dapat menggunakan target TRACE (Tampaknya dibangun di atas setidaknya Debian 5.0). Anda harus mengatur kondisi jejak Anda agar sespesifik mungkin dan menonaktifkan aturan TRACE ketika Anda tidak melakukan debug karena itu memuntahkan banyak informasi ke log.

TRACE
Target ini menandai paket-paket sehingga kernel akan mencatat setiap aturan yang cocok dengan paket-paket seperti yang melintasi tabel, rantai, aturan. (Modul ipt_LOG atau ip6t_LOG diperlukan untuk pencatatan.) Paket-paket tersebut dicatat dengan awalan string: "TRACE: tablename: chainname: type: ruleenum" di mana type dapat menjadi "rule" untuk aturan biasa, "return" untuk aturan implisit pada akhir rantai yang ditentukan pengguna dan "kebijakan" untuk kebijakan rantai bawaan. Ini hanya dapat digunakan di tabel mentah.

Jika Anda menambahkan aturan seperti ini

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Anda akan diberikan output yang terlihat seperti ini.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Sakit kepala
sumber
8
Terima kasih, ini luar biasa! Ini sebenarnya jawaban terbaik, saya berharap saya bisa menerimanya (itu adalah pertanyaan karunia, jadi jawaban yang diterima pasti). Meskipun saya tidak dapat menggunakannya di semua sistem saya (karena keterbatasan kernel), pada beberapa sistem saya bisa. Jawaban ini patut mendapat dukungan, karena sangat dekat dengan apa yang saya cari.
Chris Lercher
Saya menemukan fitur ini tadi malam ketika saya membaca kembali halaman manual iptables sehingga saya bisa menjawab pertanyaan yang berbeda. Tampaknya merupakan fitur yang relatif baru. Jangan khawatir tidak bisa menandainya sebagai diterima. Mungkin ini akan cukup dipilih dari waktu ke waktu untuk memberi saya lencana populis lain.
Zoredache
Ini benar-benar jawaban kanonik untuk melacak paket di iptables. Sayang sekali bahwa beberapa kernel terbaru tidak mengaktifkannya secara default.
Peter Grace
Berapa lama kernel mendukung TRACE? Saya telah menggunakan dengan sukses di CentOS 6.4 tetapi tidak di CentOS 6.2
sebelk
6

Tiga jawaban pada satu posting:

1) Debug dengan skrip:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) Debug oleh syslog

Dari situs web ini: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Tanpa debug, edit iptables yang bagus:

Juga ini bisa membantu: http://www.fwbuilder.org/

Marc Riera
sumber
1
Terima kasih. Poin 1) dan 3) tidak ada hubungannya dengan paket-paket berikut melalui aturan iptables, tetapi poin tentang mengarahkan kembali entri log berdasarkan "--log-level" mungkin membantu, jika saya akhirnya benar-benar harus kembali ke logging (dalam kasus sama sekali tidak ada solusi lain).
Chris Lercher
2

memiliki pertanyaan yang sama dan menemukan Zoredache menunjuk ke TRACE / ipt_LOG adalah solusinya!

Selain itu saya menemukan skrip yang menyisipkan / menghapus aturan LOG sebelum semua aturan iptables yang sedang aktif. Saya mencobanya dan menemukan itu menjadi alat yang sangat bagus. - Output mirip dengan solusi TRACE - Keuntungan: ini bekerja pada konfigurasi iptables aktif, dari mana pun itu diambil. Anda dapat menyalakan / mematikan logging dengan cepat! Anda tidak perlu memodifikasi skrip-firewall apa pun yang mungkin dihasilkan oleh Firewall Builder atau alat apa pun yang Anda gunakan ... - Kerugian: tanpa modifikasi, skrip membuat LOG-aturan untuk SEMUA aturan aktif. Sebaliknya, saat menggunakan aturan TRACE, Anda mungkin akan membatasi login ke alamat / layanan / koneksi yang ingin Anda selidiki pemrosesan iptables sekarang.

Bagaimanapun, saya suka pendekatan :) Kudos to Tony Clayton, lihat: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Salam, Chris

chris
sumber
0

Saya biasanya menggunakan penghitung paket dan byte untuk melihat bagaimana aturan bekerja dan untuk menemukan apa yang hilang atau salah.

Anda dapat melihatnya dengan "iptables -nvL".

Vi.
sumber
2
Saya dapat melihat apa yang diinginkan penulis; jika Anda mencoba untuk menguji aturan iptables Anda pada antarmuka yang sibuk hanya menonton penghitung tidak akan banyak membantu terutama jika paket tersebut cenderung cocok dengan beberapa aturan dan melompati rantai yang ditentukan pengguna dalam proses (seperti biasanya ketika memfilter alamat IP yang tidak diinginkan, dan aturan perlindungan banjir).
PP.
@PP: Tepatnya, kamu membaca pikiranku. @ Vi: Terima kasih, ini bisa membantu dalam beberapa keadaan, dan saya kadang menggunakannya. Sekarang saya butuh sesuatu yang lebih kuat.
Chris Lercher
-2

AFAIK paket IP melewati rantai aturan sampai pertandingan pertama. Jadi saya tidak benar-benar melihat apa masalahnya di sini. Jika Anda memiliki:

  1. aturan 1
  2. aturan 2
  3. aturan 3 LOG

Dan sebuah paket membuatnya menjadi log, itu berarti aturan 3 adalah aturan yang cocok pertama.

Anonim, tanpa nama
sumber
Tidak benar. Paket dapat cocok dengan beberapa aturan, dan mereka melakukannya. Kecuali aturan memiliki tindakan (suka -j DROPatau -j ACCEPT) itu hanya akan melanjutkan pencocokan lebih lanjut di rantai.
PP.