Pertanyaan IPTable dan DHCP?

Di utas saya yang lain, saya berbicara tentang beberapa hal menarik tentang kebijakan dan status iptables , sekarang saya ingin lebih memahami tentang cara kerja DHCP dan bagaimana iptables memahaminya.

ETH0 terhubung ke saklar utama saya yang menerima ip dinamis dari router saya untuk mendapatkan tidak hanya akses internet tetapi juga akses ke jaringan luar saya.

ETH1 adalah kartu internal yang terhubung ke sakelar internal tempat klien X menerima IPS mereka dari server ini

Jaringan ETH1 adalah 192.168.1.0/255.255.255.0 di mana ip server adalah 192.168.1.254.

Dari apa yang saya mengerti, dhcp adalah protokol bootp jadi bahkan jika Anda memiliki kebijakan firewall untuk MENGURANGI segalanya, jaringan Anda akan tetap menerima DHCP, yang dalam tes yang saya buat sepertinya benar.

Dari tcpdump:

root@test:~# tcpdump -i eth1 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:34:03.943928 IP 192.168.1.2.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:03.957647 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300
11:34:06.492153 IP 192.168.1.2.bootpc > 192.168.1.254.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:06.506593 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300

Saya membuat aturan log sederhana untuk melihat apa yang iptables lakukan:

root@test:~# tail -f /var/log/syslog
Oct 15 11:30:58 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9527 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:31:43 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9529 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:33:32 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9531 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:34:03 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9533 PROTO=UDP SPT=68 DPT=67 LEN=311

Ini aturan iptables saya di momment:

# deny all traffic
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

# Use stateful inspection feature to only allow incoming connections
# related to connections I have already established myself
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow all traffic on lo interface
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

Jadi, bahkan dengan KEBIJAKAN standar untuk menghapus semua hal, saya masih mendapatkan DHCP di jaringan saya sementara itu membutuhkan waktu lebih lama untuk memperbarui IP dan semacamnya.

Jika saya menambahkan aturan ikuti ke firewall saya:

$IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

Dibutuhkan BANYAK WAKTU KURANG untuk memperbarui klien dhcp.

Mempertimbangkan hal di atas:

mengapa memang butuh waktu lebih lama untuk memperbaruinya bahkan jika tidak diblokir?
apakah mungkin untuk DROP server dhcp sama sekali tanpa mematikannya?
apakah mungkin untuk MENERIMA server dhcp di dalam iptables dengan BOOTP? bagaimana itu dilakukan?

Jika Anda tahu tautan bagus, saya tidak akan keberatan mengambil banyak :)

— Guapo
sumber

Saya agak bingung dengan tcpdump dan iptables log output Anda. Apakah Anda memonitor antarmuka jaringan dalam mode promiscuous? Apakah server firewall Anda sebenarnya menggunakan DHCP untuk mengkonfigurasi NIC-nya?

— Steven Senin

@Steven server yang memiliki firewall yang merupakan yang disebutkan di atas memiliki eth0 dan eth1, eth0 menerima dhcp sebagai klien dari luar dan eth1 adalah server dhcp saya untuk jaringan internal saya yang mana yang saya bicarakan. Apa yang Anda maksud dengan Are you monitoring the network interface in promiscuous modesaya masih belajar ...

— Guapo

Oh oke. Anda benar-benar perlu menggambarkan jaringan dan server Anda dengan lebih baik jika Anda ingin orang lain memahami pertanyaan Anda!

— Steven Senin

Tentang mode promiscous: en.wikipedia.org/wiki/Promiscuous_mode

— Steven Monday

@ Seven akan melakukan itu sekarang terima kasih untuk menunjukkan, apakah Anda pikir saya harus menentukan hal lain selain tata letak jaringan?

— Guapo

Jawaban:

Saya akan menjawab # 2: Tidak.

Ketika mendapatkan alamat IP, daemon dhcp membuat socket mentah ke antarmuka jaringan dan menangani protokol UDP itu sendiri. Dengan demikian paket UDP tidak pernah melalui iptables.

Alasan daemon dhcp harus mengimplementasikan UDP adalah karena kernel hanya dapat menangani UDP (sebenarnya semua TCP / IP suite) ketika antarmuka memiliki alamat IP. Daemon dhcp sebelumnya akan memberikan antarmuka alamat IP 0,0.0.0 tetapi itu tidak lagi berfungsi.

— Mark Wagner
sumber

soket paket . soket mentah jangan pergi melalui iptables. afaict. unix.stackexchange.com/a/447524/29483

— sourcejedi

Menambahkan

$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

harus membuat pembaruan DHCPD lebih cepat :) Ini akan berfungsi baik sisi INPUT dan OUTPUT. Anda dapat DROP dhcpd dengan ebtables, bukan dengan iptables. Mendengarkan DHCPD pada 0.0.0.0, tidak dalam IP

— Ta Coen
sumber

+1 Saya memilikinya di INPUT dan butuh jumlah waktu yang sama seolah-olah saya tidak memilikinya pada aturan saya. Ketika saya membuatnya OUTPUT itu membuat perbedaan besar. Saya akan membaca tentang ebtables, terima kasih.

— Guapo

$ IPT -I INPUT -i $ INTIF -s 0/0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

— Ta Coen

hanya mencoba yang di atas dan masih terlalu lama dibandingkan dengan menggunakan aturan OUTPUT.

— Guapo

Karena polisnya DROP, maka Anda harus menggunakan INPUT dan OUTPUT.

— Ta Coen

Pengamatan saya baru-baru ini, di OpenWRT Kamikaze 7.09 = 2.4.34 dan udhcpc dari busybox 1.4.2:

Saya memiliki kebijakan "MENERIMA" dalam rantai OUTPUT, dan ke arah INPUT, awalnya saya mengandalkan aturan klasik tangkap-semua ini:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

untuk memungkinkan tanggapan DHCP di (ke udhcpc saya) pada antarmuka WAN. Yaitu, ini adalah di mana server DHCP upstream ISP saya memberikan Alamat IP kepada saya.

Pikirkan perbedaan antara pertukaran DHCP awal (temukan, tawarkan, minta, ACK) dan perpanjangan sewa DHCP (permintaan, ACK).

Setelah boot, udhcpc dimulai dengan pertukaran awal penuh. Pertukaran itu akan berhasil. Dan satu atau dua pembaruan lagi akan berhasil juga - hanya permintaan dan pengakuan. Server DHCP ISP saya biasanya meminta waktu pembaruan sekitar satu jam hingga 1,5 jam, sehingga klien DHCP saya meminta pembaruan setiap 30 hingga 45 menit (perilaku ini didasarkan pada RFC).

Tapi, tentang pembaruan ketiga atau keempat, itu akan mulai menarik. TCPdump akan menunjukkan sekitar tiga upaya pembaruan, diikuti oleh pertukaran awal penuh - yang dalam rentang waktu hanya beberapa menit atau bahkan detik. Seolah udhcpc tidak suka apa yang dikembalikan :-( dan akhirnya akan puas dengan pertukaran penuh. Setelah itu, pembaruan lain dalam setengah jam akan berhasil ... dan cerita akan terulang lagi.

Saya menemukan, bahwa mungkin pelacakan koneksi di kernel yang salah. Seolah-olah entri conntrack berakhir setelah dua jam atau lebih, dan pembaruan DHCP kemudian gagal karena ACK dari server tidak benar-benar membuatnya menjadi udhcpc mendengarkan pada socket. Perhatikan bahwa tcpdump (libpcap) mendengarkan pada antarmuka mentah dan dapat melihat semua paket masuk, sebelum mereka tunduk pada iptables. Setelah udhcpc menyerah pembaruan dan, putus asa, mencoba memulai dari awal menggunakan pertukaran penuh (dimulai dengan DISCOVER), kernel membuat entri conntrack baru dan dapat memahami paket-paket terkait untuk beberapa waktu lagi ...

Benar saja, begitu saya menambahkan sesuatu seperti:

iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT

pembaruan tampaknya bekerja selamanya.

Anda mungkin menemukan tcpdump cmdline args berikut berguna:

tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68

Catatan: permintaan -vvuntuk keluaran verbose dissector. eth0.1adalah port WAN saya (juga antarmuka "NAT luar").

Atribut yang menarik dalam paket ACK adalah bidang LT: = disarankan / waktu sewa maksimum yang diberikan dalam detik. Permintaan DHCP dikirim dari port 68 ke port 67. Respons datang dari port 67 ke port 68.

— frr
sumber

Kisah Anda tidak masuk akal. Tidak masalah apakah awal atau pembaruan, pertukaran DHCP selalu dimulai oleh klien yang mengirim dari port 68 ke port 67, baik ke IP tertentu atau sebagai siaran. Dan dengan ACCEPT keluar, ini akan selalu berhasil. Balasan dari tujuan keluar harus selalu melewati yang masuk oleh aturan ESTABLISHED, jadi pembaruan harus bekerja selamanya hanya dengan aturan ESTABLISHED karena setiap pembaruan juga memperbaharui atau menciptakan kembali kondisi penautan.

— Mecki

Perpanjangan mengirim permintaan openwrt:68 -> dhcpserver:67dan ACK akan dhcpserver:67 -> openwrt:68. Ini dianggap sebagai DIDIRIKAN dan akan berlalu. Jika keadaan conntrack lama kedaluwarsa, ini menetapkan yang baru. Jika ada masalah, itu hanya bisa dengan pertukaran awal seperti DISCOVER 0.0.0.0:68 -> 255.255.255.255:67dan PENAWARAN akan dhcpserver:67 -> new-openwrt:68, yang tidak dihitung sebagai DIDIRIKAN. Ini hanya berfungsi karena DHCP biasanya mem-bypass iptables dengan soket paket di Linux, jika tidak diperlukan aturan masuk yang memungkinkan paket dari port UDP 67 atau ke port UDP 68.

— Mecki

Anda juga mengatakan bahwa beberapa pembaruan memang berhasil, namun setiap pembaruan yang berhasil juga akan memperbarui keadaan conntrack, jadi jika status conntrack Anda berakhir setelah 2 jam, pembaruan akan memperpanjang lagi dengan 2 jam lagi dan seterusnya dan karenanya tidak akan pernah berakhir. . Namun, batas waktu konogasi default untuk UDP hanya 30 detik dan bukan 2 jam dan saya ragu bahwa OpenWRT telah mengubah itu menjadi 2 jam karena itu akan gila. Jadi ceritamu tampaknya benar-benar salah bagiku.

— Mecki

@Mecki, terima kasih atas umpan baliknya yang berharga :-) Sekarang, respons saya sudah berusia 4 tahun. Sekitar satu tahun yang lalu, ASUS WL500G Deluxe saya mulai sangat flakey (setelah sekitar 12 tahun runtime, karena penggantian kapasitor) dan saya membuang Kamikaze tua itu beserta perangkat kerasnya. Saat ini saya sedang menjalankan OpenWRT saat ini dengan menggunakan TP-Link AP modern, dan setelah beberapa pemikiran, saya belum menggunakan kembali skrip firewall lama saya. OpenWRT sekarang tampaknya memiliki firewall yang bagus di luar kotak ... Maksud saya, saya tidak dapat memverifikasi klaim masa lalu saya. Yang saya tahu adalah bahwa aturan iptables tambahan memang membantu.

— FRR