IPTables và câu hỏi DHCP?


8

Về chủ đề khác của tôi, tôi đã nói về một số điều thú vị về chính sách và trạng thái của iptables , bây giờ tôi muốn hiểu thêm về cách DHCP hoạt động và cách iptables hiểu nó.

ETH0 được kết nối với bộ chuyển mạch chính của tôi để nhận ip động từ bộ định tuyến của tôi để có được không chỉ truy cập internet mà còn là quyền truy cập vào mạng bên ngoài của tôi.

ETH1 là thẻ nội bộ được kết nối với bộ chuyển mạch bên trong nơi máy khách X nhận IPS của họ từ máy chủ này

Mạng ETH1 là 192.168.1.0/255.255.255.0 trong đó ip máy chủ là 192.168.1.254.

Theo những gì tôi hiểu, dhcp là một giao thức khởi động, vì vậy ngay cả khi bạn có chính sách tường lửa để DROP mọi thứ, mạng của bạn vẫn sẽ nhận được DHCP, trong các thử nghiệm mà tôi đã làm là đúng.

Từ 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

Tôi đã thực hiện một quy tắc đăng nhập đơn giản để xem iptables làm gì:

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

Đây là quy tắc iptables của tôi tại thời điểm:

# 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

Vì vậy, ngay cả khi CHÍNH SÁCH mặc định bỏ mọi thứ, tôi vẫn nhận được DHCP trên mạng của mình trong khi phải mất nhiều thời gian hơn để làm mới IP và như vậy.

Nếu tôi thêm quy tắc theo vào tường lửa của mình:

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

Sẽ mất rất nhiều thời gian để cập nhật bất kỳ dhcp khách hàng nào.

Xem xét ở trên:

  1. Tại sao nó thực sự mất nhiều thời gian hơn để cập nhật nó thậm chí nghĩ rằng nó không bị chặn?
  2. Có thể DROP máy chủ dhcp mà không cần tắt nó không?
  3. có thể CHẤP NHẬN máy chủ dhcp trong iptables với BOOTP không? làm thế nào được thực hiện?

Nếu bạn biết các liên kết tốt, tôi sẽ không mất nhiều :)


Tôi hơi bối rối bởi đầu ra nhật ký tcpdump và iptables của bạn. Bạn đang theo dõi giao diện mạng ở chế độ lăng nhăng? Là máy chủ được tường lửa của bạn thực sự sử dụng DHCP để cấu hình NIC của nó?
Steven Thứ Hai

@Steven máy chủ có tường lửa được đề cập ở trên có eth0 và eth1, eth0 nhận dhcp với tư cách là máy khách từ bên ngoài và eth1 là máy chủ dhcp của tôi cho mạng nội bộ của tôi, đây là máy chủ mà tôi đang nói đến. Ý bạn là gì khi Are you monitoring the network interface in promiscuous modetôi vẫn đang học ...
Guapo

Ồ được thôi. Bạn thực sự cần mô tả tốt hơn về mạng và máy chủ của mình nếu bạn muốn bất cứ ai hiểu câu hỏi của bạn!
Steven Thứ Hai


@Steven sẽ làm điều đó ngay bây giờ nhờ vào việc chỉ ra, bạn có nghĩ rằng tôi phải chỉ định bất cứ điều gì khác ngoài bố cục mạng không?
Guapo

Câu trả lời:


13

Tôi sẽ trả lời # 2: Không.

Khi nhận địa chỉ IP, trình nền dhcp sẽ tạo một ổ cắm thô cho giao diện mạng và tự xử lý giao thức UDP. Do đó, các gói UDP không bao giờ đi qua iptables.

Lý do trình nền dhcp phải triển khai UDP là kernel chỉ có thể xử lý UDP (thực tế là tất cả bộ TCP / IP) khi giao diện có địa chỉ IP. Các trình tiện ích dhcp trước đây trước tiên sẽ cung cấp cho giao diện địa chỉ IP là 0,0.0.0 nhưng không còn hoạt động.


ổ cắm gói . socket liệu làm đi qua iptables. afaict. unix.stackexchange.com/a/447524/29483
sourcejedi

5

Thêm

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

sẽ làm cho cập nhật DHCPD nhanh hơn :) Nó sẽ hoạt động cả hai bên INPUT và OUTPUT. Bạn có thể DROP dhcpd với ebtables, không phải với iptables. Nghe DHCPD ở 0.0.0.0, không nằm trong IP


+1 Tôi đã có nó trên INPUT và nó đã mất cùng một khoảng thời gian như thể tôi không có nó theo quy tắc của mình. Khi tôi thực hiện nó, nó đã tạo ra sự khác biệt lớn. Tôi sẽ đọc về ebtables cảm ơn.
Guapo

$ IPT -I INPUT -i $ INTIF -s 0/0 -p udp --dport 67:68 --sport 67:68 -j CHẤP NHẬN
Ta Coen

chỉ thử ở trên và vẫn mất quá nhiều thời gian so với sử dụng quy tắc OUTPUT.
Guapo

Vì chính sách là DROP, nên bạn sẽ sử dụng cả INPUT và OUTPUT.
Ta Coen

3

Quan sát gần đây của tôi, trên OpenWRT Kamikaze 7.09 = 2.4.34 và udhcpc từ busybox 1.4.2:

Tôi có chính sách "CHẤP NHẬN" trong chuỗi OUTPUT và theo hướng INPUT, ban đầu tôi đã dựa vào quy tắc bắt tất cả cổ điển này:

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

để cho phép các phản hồi DHCP trong (với udhcpc của tôi) trên giao diện WAN. Tức là, đây là nơi máy chủ DHCP ngược dòng của ISP gán Địa chỉ IP cho tôi.

Lưu ý sự khác biệt giữa trao đổi DHCP ban đầu (khám phá, cung cấp, yêu cầu, ack) và gia hạn thuê DHCP (yêu cầu, ack).

Sau khi khởi động, udhcpc bắt đầu bằng trao đổi ban đầu đầy đủ. Sự trao đổi đó sẽ thành công. Và một hoặc hai lần gia hạn khác cũng sẽ thành công - chỉ cần một yêu cầu và xác nhận. Máy chủ DHCP của ISP của tôi thường yêu cầu thời gian gia hạn khoảng một giờ đến 1,5 giờ, do đó, máy khách DHCP của tôi yêu cầu gia hạn cứ sau 30 đến 45 phút (hành vi này dựa trên RFC).

Nhưng, vào lần đổi mới thứ ba hoặc thứ tư, nó sẽ bắt đầu trở nên thú vị. TCPdump sẽ hiển thị khoảng ba lần thử đổi mới, sau đó là một trao đổi ban đầu đầy đủ - rằng trong khoảng thời gian chỉ vài phút hoặc thậm chí vài giây. Như thể udhcpc không thích những gì nó nhận lại :-( và cuối cùng sẽ hài lòng với việc trao đổi đầy đủ. Sau đó, một lần đổi mới sau nửa giờ nữa sẽ thành công ... và câu chuyện sẽ lặp lại.

Tôi nhận ra rằng có lẽ việc theo dõi kết nối trong kernel đã bị lỗi. Như thể mục nhập conntrack hết hạn sau hai giờ hoặc lâu hơn, các lần gia hạn DHCP sau đó không thành công vì ACK từ máy chủ không thực sự khiến nó nghe udhcpc trên ổ cắm. Lưu ý rằng tcpdump (libpcap) lắng nghe trên giao diện thô và có thể thấy tất cả các gói đến, trước khi chúng phải tuân theo iptables. Khi udhcpc từ bỏ gia hạn và, trong tuyệt vọng, cố gắng bắt đầu lại từ đầu bằng cách sử dụng một trao đổi đầy đủ (bắt đầu với DISCOVER), hạt nhân thiết lập một mục nhập conntrack mới và có thể hiểu các gói liên quan trong một thời gian nữa ...

Chắc chắn, một khi tôi đã thêm một cái gì đó như:

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

các gia hạn dường như làm việc mãi mãi.

Bạn có thể thấy các cmdline tcpdump sau đây hữu ích:

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

Lưu ý: các -vvyêu cầu cho đầu ra mổ xẻ dài dòng. eth0.1là cổng WAN của tôi (cũng là giao diện "NAT bên ngoài").

Một thuộc tính thú vị trong các gói ACK là LT: field = đề nghị / thời gian thuê được cấp tối đa tính bằng giây. Yêu cầu DHCP được gửi từ cổng 68 đến cổng 67. Phản hồi đến từ cổng 67 đến cổng 68.


Câu chuyện của bạn không có ý nghĩa. Bất kể là ban đầu hay gia hạn, trao đổi DHCP luôn được bắt đầu bằng cách máy khách gửi từ cổng 68 đến cổng 67, đến một IP cụ thể hoặc dưới dạng phát sóng. Và với sự chấp thuận đi, điều này sẽ luôn hoạt động. Một câu trả lời từ đích đến sẽ luôn luôn đi qua đến bởi quy tắc THÀNH LẬP, do đó, việc gia hạn sẽ hoạt động mãi mãi chỉ với quy tắc THÀNH LẬP vì mọi đổi mới cũng sẽ gia hạn hoặc tạo lại trạng thái conntrack.
Mecki

Một gia hạn sẽ gửi một yêu cầu openwrt:68 -> dhcpserver:67và ACK sẽ được dhcpserver:67 -> openwrt:68. Điều này được tính là THÀNH LẬP và sẽ vượt qua. Nếu trạng thái conntrack cũ hết hạn, điều này sẽ thiết lập một trạng thái mới. Nếu có vấn đề, chỉ có thể là với trao đổi ban đầu với tư cách là KHÁM PHÁ 0.0.0.0:68 -> 255.255.255.255:67và CUNG CẤP sẽ dhcpserver:67 -> new-openwrt:68không được tính là THÀNH LẬP. Điều này chỉ hoạt động vì DHCP thường bỏ qua iptables bằng ổ cắm gói trên Linux, nếu không thì phải có quy tắc đến cho phép các gói từ cổng UDP 67 hoặc tới cổng UDP 68.
Mecki

1
Ngoài ra, bạn nói rằng một số lần gia hạn đã thành công, nhưng mỗi lần gia hạn thành công cũng sẽ làm mới trạng thái conntrack, vì vậy nếu trạng thái conntrack của bạn hết hạn sau 2 giờ, thì một lần gia hạn sẽ kéo dài thêm 2 giờ nữa và cứ thế nó sẽ không bao giờ hết hạn . Tuy nhiên, thời gian chờ conntrack mặc định cho UDP chỉ là 30 giây chứ không phải 2 giờ và tôi nghi ngờ rằng OpenWRT đã thay đổi điều đó thành 2 giờ vì điều đó thật điên rồ. Vì vậy, câu chuyện của bạn dường như hoàn toàn thiếu sót đối với tôi.
Mecki

@Mecki, cảm ơn về phản hồi có giá trị :-) Đến giờ, phản hồi của tôi đã được 4 tuổi. Khoảng một năm trước, ASUS WL500G Deluxe của tôi đã bắt đầu bị hỏng hoàn toàn (sau khoảng 12 năm chạy, do thay thế tụ điện) và tôi đã cười thầm rằng Kamikaze cũ cùng với phần cứng. Ngay bây giờ tôi đang chạy OpenWRT hiện tại trên AP-Link AP hiện đại và sau một số suy nghĩ, tôi đã không sử dụng lại các tập lệnh tường lửa cũ của mình. OpenWRT bây giờ dường như có một tường lửa tốt ... Tôi muốn nói rằng tôi không thể xác minh các khiếu nại trước đây của mình. Tất cả những gì tôi biết là quy tắc iptables thêm đã giúp.
FRR
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.