环境：一个宿舍楼层，一台 Linux 做 NAT，带十几台电脑，一个普通HUB，大家集资购买
因为网络中有非法 DHCP 服务器，影响了大家正常 IP 分配（估计是有人用VMWARE），我想了一个方法来找出那个电脑
[root@platinum root]# tcpdump -e -i eth1 -nn port 67 -c 4 2>;&1|awk '/bootp/{print $2" -->; "$3}'
0:a:e6:a9:64:a2 -->; ff:ff:ff:ff:ff:ff
0:e0:4c:39:6d:96 -->; 0:a:e6:a9:64:a2
0:a:e6:a9:64:a2 -->; ff:ff:ff:ff:ff:ff
0:e0:4c:39:6d:96 -->; 0:a:e6:a9:64:a2
[root@platium root]#
原理是听包，找到那个电脑的 MAC，因为 IP 一般人都会改的，MAC 不一定
用这个方法找出他的 MAC，然后在 NAT 机器上面禁止掉他
前提：因为资金问题，不能购买带管理的交换，因此仅从技术方面分析，帮助那些无助的朋友们分析解决问题
回复于：2005-07-14 15:36:53
在听包的时候能不能只抓DHCPOFFER的包并显示出来?这样的话更容易来找一点
回复于：2005-07-14 15:41:48
引用：原帖由 "河里的鱼"]在听包的时候能不能只抓DHCPOFFER的包并显示出来?这样的话更容易来找一点
发表：
我还没想到什么好的办法，网络中的数据太多了，用端口来过滤是肯定的
上面的方法，我选择了 67 端口，因为 dhcp-server 用 UDP/67，dhcp-client 用 UDP/68
如果自己不做 dhcp-server，用上面的方法没有问题，而且抓到的包很少
如果说“更容易一些”，可能也就这样最容易了吧 :D
回复于：2005-07-14 15:45:57
呵,有一个思路:
在客户机请求选用的时候会发一个包
0.0.0.0/68 --- 255.255.255.255/67
只来捕捞这一个数据包,而且相对来说审视会不会更容易一点呢?
不知道有没有错解的地方?
回复于：2005-07-14 15:49:26
引用：原帖由 "河里的鱼" 发表：
呵,有一个思路:
在客户机请求选用的时候会发一个包
0.0.0.0/68 --- 255.255.255.255/67
只来捕捞这一个数据包,而且相对来说审视会不会更容易一点呢?
不知道有没有错解的地方?
client IP 应该是自己的才对
这个思路倒是可以，不过传输是双向的，大概他们之间要有 2 去 2 回共 4 个包
如果单向的话，也有 2 个
回复于：2005-07-14 15:51:25
嗯,想不到什么了,关注此帖
回复于：2005-07-14 16:31:15
我就觉得ipconfig/all得到dhcp server的ip,改成一个网段就可以得到mac了.我觉得这样比较方便^_^
我一般这么解决,有时顺便也用nmap扫一下看看是个什么设备,是windows 就对其135,139等 syn-flood,如果是公司生产的设备就ssh上去关掉dhcp(可以不管该设备在哪里).
回复于：2005-07-14 16:32:53
直接superscan扫描DHCP的port可以么？
回复于：2005-07-14 16:35:30
记不清了,我记得dhcp该是在链路层上广播的啊.不过好象封装成udp了.
感觉扫udp应该扫不到吧.
回复于：2005-07-14 16:55:40
引用：原帖由 "starwater"]直接superscan扫描DHCP的port可以么？
发表：
欢迎讨论：）
具体说说看？
另外由这个，引发了我又一个问题
根据 RFC 2131 的内容，我在 DHCP 服务器上封掉了 UDP/67，但 client 仍然可以通过我获取 IP
又做了一个试验，干脆 service iptables stop，然后 iptables -P INPUT DROP，之后发现 client 依然可以获取 IP，很是奇怪
大家说说这是怎么回事
回复于：2005-07-14 17:04:40
不会是从别的DHCP获取的吧~~~~
回复于：2005-07-14 17:11:00
不不，我是自己做的试验，在家
我家 3 台电脑，一个做 NAT，带另外两个上网
我是在 NAT 上做策略，然后用我自己的电脑去获取 dhcp IP 的
回复于：2005-07-14 17:25:40
那这个问题就奇怪了,你再做一次,
抓个包看看是怎么回事?
回复于：2005-07-14 17:51:16
引用：原帖由 "河里的鱼" 发表：
那这个问题就奇怪了,你再做一次,
抓个包看看是怎么回事?
OK，稍后我把所有试验过程贴出来让大家看
回复于：2005-07-14 17:52:32
引用：原帖由 "platinum" 发表：
OK，稍后我把所有试验过程贴出来让大家看
TKS~~~~~~~~~
回复于：2005-07-14 19:42:41
引用：原帖由 "platinum" 发表：
欢迎讨论：）
具体说说看？
另外由这个，引发了我又一个问题
根据 RFC 2131 的内容，我在 DHCP 服务器上封掉了 UDP/67，但 client 仍然可以通过我获取 IP
又做了一个试验，干脆 service iptables stop，然后 ..........
关注！
我觉得可能是这样的：对于dhcp广播的包，应该是不符合INPUT这个链的，但是我也不知道该是哪个，但是如果将OUTPUT的链DROP掉，估计就该获取不到IP了吧？
回复于：2005-07-14 20:13:04
引用：原帖由 "achaoge" 发表：
应该是不符合INPUT这个链的，但是我也不知道该是哪个，但是如果将OUTPUT的链DROP掉，估计就该获取不到IP了吧？
[color=red]INPUT[/color] 链不管用的话，没理由 [color=red]OUTPUT[/color] 链管用的，二者是[color=red]同一层次的并列关系[/color]
下面看我做的两个试验
试验一：
引用：
[root@PT-LINUX root]# iptables -F INPUT
[root@PT-LINUX root]# iptables -F FORWARD
[root@PT-LINUX root]# iptables -F OUTPUT
[root@PT-LINUX root]# iptables -P INPUT DROP
[root@PT-LINUX root]# iptables -P FORWARD DROP
[root@PT-LINUX root]# iptables -P OUTPUT DROP
[root@PT-LINUX root]# tcpdump -nn -i eth1 -e port 67
tcpdump: listening on eth1
20:03:20.019578 0:a:e6:a9:64:a2 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 >; 255.255.255.255.67: xid:0x6c5e750e [|bootp]
20:03:20.020444 0:e0:4c:39:6d:96 0:a:e6:a9:64:a2 0800 342: 172.25.39.254.67 >; 172.17.39.249.68: xid:0x6c5e750e Y:172.17.39.249 S:172.25.39.254 [|bootp] [tos 0x10]
20:03:20.021149 0:a:e6:a9:64:a2 ff:ff:ff:ff:ff:ff 0800 353: 0.0.0.0.68 >; 255.255.255.255.67: xid:0x6c5e750e [|bootp]
20:03:20.215595 0:e0:4c:39:6d:96 0:a:e6:a9:64:a2 0800 342: 172.25.39.254.67 >; 172.17.39.249.68: xid:0x6c5e750e Y:172.17.39.249 S:172.25.39.254 [|bootp] [tos 0x10]
4 packets received by filter
0 packets dropped by kernel
[root@PT-LINUX root]#
试验结果：
清空 filter 表的所有规则，并将 filter 表各个链的默认规则设置为 DROP，client 仍然可以从本机这台机器获取 IP
试验二：
引用：
[root@PT-LINUX root]# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: mangle filter nat [ OK ]
Unloading iptables modules: [ OK ]
[root@PT-LINUX root]# iptables -t mangle -A PREROUTING -j DROP
[root@PT-LINUX root]# tcpdump -nn -i eth1 -e port 67
tcpdump: listening on eth1
20:05:28.404501 0:a:e6:a9:64:a2 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68 >; 255.255.255.255.67: xid:0x94262a24 [|bootp]
20:05:29.000447 0:e0:4c:39:6d:96 0:a:e6:a9:64:a2 0800 342: 172.25.39.254.67 >; 172.17.39.249.68: xid:0x94262a24 Y:172.17.39.249 S:172.25.39.254 [|bootp] [tos 0x10]
20:05:29.001226 0:a:e6:a9:64:a2 ff:ff:ff:ff:ff:ff 0800 353: 0.0.0.0.68 >; 255.255.255.255.67: xid:0x94262a24 [|bootp]
20:05:31.059376 0:e0:4c:39:6d:96 0:a:e6:a9:64:a2 0800 342: 172.25.39.254.67 >; 172.17.39.249.68: xid:0x94262a24 Y:172.17.39.249 S:172.25.39.254 [|bootp] [tos 0x10]
4 packets received by filter
0 packets dropped by kernel
[root@PT-LINUX root]#
试验结果：
这次停掉所有规则，然后把 netfilter 最先处理的 PREROUTING 链禁止掉，迫使它拦截一切数据包，结果 client 依然可以获取到 IP
回复于：2005-07-14 20:47:56
我觉得DHCP服务器端扫不到端口,
印象中那只是个用UDP封装的报文.广播还是在链路上广播的,跟ip无关.
打开DHCP服务,应该也扫不到端口才对...
有问题请指出.
回复于：2005-07-14 21:24:03
引用：原帖由 "双眼皮的猪" 发表：
我觉得DHCP服务器端扫不到端口,
印象中那只是个用UDP封装的报文.广播还是在链路上广播的,跟ip无关.
打开DHCP服务,应该也扫不到端口才对...
有问题请指出.
我再去看看 RFC 2131/2132
回复于：2005-07-14 22:07:30
RFC 2131 中提到一些 UDP 的内容
引用：
DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the 'DHCP server' port (67), and DHCP
messages from a server to a client are sent to the 'DHCP client' port
(68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages.
但没谈到封装的问题
回复于：2005-07-14 22:44:32
我觉得和封装没什么关系，白金的试验就是说明了iptables对dhcp请求不起作用。
因为偶这里没有linux环境，而且偶也不熟悉，但是结论不外乎以下几种：
白金的iptables有bug；
iptables是基于ip处理的，不是网卡的ip包不入链；
只是dhcp包不过iptables。
不考虑bug的情况，如果是后两种情况，可以设计个试验区分开来。
偶的解决方法其实也挺简单，不管过不过iptables，首先在接口上能抓到，那么在接口上设置只接受信任服务器所发来的dhcp报文就可以了；换句话说，交换机虽然不支持监控，但是在client端还可以做些安全处理。
这样子虽然找不到谁有问题，但是可以避免受问题的影响。
至于具体能不能实现，偶就不知道了，大家可以考虑下。
回复于：2005-07-14 22:47:53
http://comm.ccidnet.com/pub/article/c1716_a198775_p1.html
这里原理很详细了，也许有点启发
上面说win可以对dhcp sever提供认证，不合法的dhcp是不能提供服务的
不知道redhat行不行
回复于：2005-07-14 23:09:56
找了一篇文章，也许能得到些启发
http://www.isc.org/sw/dhcp/authoritative.php
还没领会其中的意思。。。。
回复于：2005-07-14 23:28:15
引用：原帖由 "platinum" 发表：
找了一篇文章，也许能得到些启发
http://www.isc.org/sw/dhcp/authoritative.php
还没领会其中的意思。。。。
应该和你要做的没有关系，这个是设置server端的，目的应该是防止dhcp地址耗尽或者将有用的地址分配出去。
换句话说，基本和我们的要求是相反地……
回复于：2005-07-14 23:46:25
引用：原帖由 "cnadl" 发表：
应该和你要做的没有关系，这个是设置server端的，目的应该是防止dhcp地址耗尽或者将有用的地址分配出去。
换句话说，基本和我们的要求是相反地……
嗯，我刚看明白，正如 cnadl 所说，这个不是做 dhcp 验证的
关于 Linux 的资料没有查到。。。。
回复于：2005-07-15 08:01:45
还没搞定啊？
昨晚讨论到将近12点？佩服。。。
群里说。。 :roll:
回复于：2005-07-15 08:35:46
请问支持网管的交换机可以防止这个现象是吗?那么该如何做呢?(需要用到交换机的哪部分功能)
另想请问下QQ群号码,加入学习学习linux知识.
回复于：2005-07-15 08:47:47
我晕,昨天晚上公司不在让在了,没办法就回家了,没等到结果出来,早上来居然这么多了,还有这么资料?
回复于：2005-07-15 08:54:13
iptables -N bootp_packets
iptables -A bootp_packets -p UDP -s 0/0 --source-port 68 -j DROP
??
回复于：2005-07-15 09:12:19
昨天晚上躺在床上,想到广播方式能不能用c/s的思维方式来理解^_^
我tcpip不熟悉,白金看看^_^
回复于：2005-07-15 09:14:35
如果白金的IPTABLES没有BUG的话,那么认证的时候是二层的防火墙对它根本没有起到作用,就像ARPING
回复于：2005-07-15 09:30:30
localhost DHCPDISCOVER ->; ff:ff:ff:ff:ff:ff
dhcp server ->; localhost DHCPOFFER
localhost DHCPREQUEST ->; ff:ff:ff:ff:ff:ff
dhcp server ->; localhost DHCPACK
这个是 DHCP 的运作过程
引用：
Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
uicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client's IP address
cannot be delivered until the client has been configured with an IP
address).
回复于：2005-07-15 13:24:27
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
这是DHCP用的网段把?
回复于：2005-07-15 13:27:41
引用：原帖由 "wheel" 发表：
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
这是DHCP用的网段把?
这是Automatic Private IP Addressing (APIPA) 段 :roll:
回复于：2005-07-15 14:55:13
引用：原帖由 "waker" 发表：
iptables -A bootp_packets -p UDP -s 0/0 --source-port 68 -j DROP
如果我没记错0/32就可以了。
回复于：2005-07-15 15:03:03
引用：原帖由 "cnadl" 发表：
引用：原帖由 "waker" 发表：
iptables -A bootp_packets -p UDP -s 0/0 --source-port 68 -j DROP
如果我没记错0/32就可以了。
这是什么东西啊？
回复于：2005-07-15 15:09:57
引用：原帖由 "platinum" 发表：
这是什么东西啊？
0.0.0.0/255.255.255.255
dhcp有用到这个ip，我忘记是client的源地址还是目的地址了。
回复于：2005-07-15 15:16:56
试验一：
INPUT、OUTPUT 都 DROP 了，不比 0.0.0.0/255.255.255.255 的方法好嘛？
试验二：
PREROUTING 都 DROP 了，不必 0.0.0.0/255.255.255.255 的方法好嘛？
我的匹配方式比上面的要宽松，都没有匹配到，难道比我更严格的匹配方式就可以匹配上？不可能。。。。
回复于：2005-07-22 11:25:16
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
关于UDP端口的扫描，这个是nmap的一段man，可以看看，UDP也是可以扫描的，只是通过icmp的辅助来识别，而且我的映象中比较慢来着。
另外，开启ntop服务，可以很容易的找到网内机子所提供的服务，找到dhcp服务器不是问题。
而且这么多的帖子看下来，我没明白是NAT提供dhcp还是另外一台机子提供dhcp。也就是一直没明白这个试验的拓扑是怎样的。
回复于：2005-07-22 12:08:07
能不能做个试验，看看除dhcp以外，其它的协议在防火墙drop的情况下能不能被dump出来，例如ping
主要想测试一下tcpdump的工作方式是直接从网卡接收数据包还是经过iptables过滤后在从kernel接收数据包
如果是通过驱动直接从网卡接收数据包，iptables当然不起作用啦
回复于：2005-07-22 12:19:46
tcpdump 是直接从网卡设备上读取数据的，即使禁止了 ping，client 无法 ping 通，但依然可以抓到包
“如果是通过驱动直接从网卡接收数据包，iptables当然不起作用啦”但这又能证明什么呢？
回复于：2005-07-22 14:47:03
引用：原帖由 "platinum" 发表：
tcpdump 是直接从网卡设备上读取数据的，即使禁止了 ping，client 无法 ping 通，但依然可以抓到包
“如果是通过驱动直接从网卡接收数据包，iptables当然不起作用啦”但这又能证明什么呢？
这就证明了，无论怎么样设置iptables，tcpdump依然可以捕捉到dhcp发出的udp广播包
回复于：2005-07-22 15:04:08
DHCP是基于UDP层上的协议
而iptable也工作于网络层以上
应该不至于不起作用
回复于：2005-07-22 15:24:09
引用：原帖由 "bingosek" 发表：
这就证明了，无论怎么样设置iptables，tcpdump依然可以捕捉到dhcp发出的udp广播包
我并没有否认过这一点啊，这与 iptables 拦截不住又有什么关系呢？
回复于：2005-07-22 15:40:12
楼主做实验的时候先把dhcp-client的ip release一下，看看试验试验结果。
回复于：2005-07-22 15:43:00
呀，我看错了：）
回复于：2005-07-22 15:43:23
对了，试试将ip_forward给禁用。
回复于：2005-07-22 15:56:55
试试用telnet或扫描工具看看server上port 67是打开的还是关闭的
回复于：2005-07-22 16:00:18
引用：原帖由 "suntoltti"]楼主做实验的时候先把dhcp-client的ip release一下，看看试验试验结果。
发表：
是的，我每一次都是先释放后获取
在 WIN 里，命令是
ipconfig/release
ipconfig/renew
回复于：2005-07-22 16:01:20
我也发现过一些有趣儿的现象:我把一个用户的IP的input和output全drop了,可是发现他还能上msn和qq,只是不能用上网不能ftp,也有点不理解....
回复于：2005-07-22 16:01:30
引用：原帖由 "NetDC"]对了，试试将ip_forward给禁用。
发表：
ip_forward 与这又有什么关系呢？
我已尝试过将 PREROUTING 全部禁止，但依然没用，根本就走不到 route 的过程
回复于：2005-07-22 16:02:15
引用：原帖由 "NetDC"]对了，试试将ip_forward给禁用。
发表：
不知道和这个有没有关系.
回复于：2005-07-22 16:02:30
引用：原帖由 "bingosek"]试试用telnet或扫描工具看看server上port 67是打开的还是关闭的
发表：
dhcp 做服务的时候，用的是 udp 协议，你说的方法只能探测 tcp
回复于：2005-07-22 16:03:38
引用：原帖由 "platinum" 发表：
ip_forward 与这又有什么关系呢？
我已尝试过将 PREROUTING 全部禁止，但依然没用，根本就走不到 route 的过程
哪在server上port 67是不是打开的？如果port 67还是打开的，对于port 67的连接不是被refused掉的话，就应该是iptables的问题了
回复于：2005-07-22 16:04:27
引用：原帖由 "我爱钓鱼"]我也发现过一些有趣儿的现象:我把一个用户的IP的input和output全drop了,可是发现他还能上msn和qq,只是不能用上网不能ftp,也有点不理解....
发表：
你的那个情况是因为数据包是基于状态的，你默认 DROP 的仅仅是 NEW，ESTABLISHED 和 RELATED 的没有禁止，因此依然能上
而 ftp 的传输是临时需要开端口的，因此他的 NEW 会被 DROP，造成上不了的状况
你的这个问题与本讨论主题无关
回复于：2005-07-22 16:06:15
引用：原帖由 "bingosek" 发表：
哪在server上port 67是不是打开的？
不懂你的意思。。。。。
client 能获得 IP，netstat -lnp 能看到端口监听，端口当然是开着的
不过，和 iptables 无法阻止 DHCP 的这个奇怪现象又有什么联系呢？
回复于：2005-07-22 16:09:15
我是说，我想了解从client的角度看，server上的dhcp端口是不是已经给iptables block住了
回复于：2005-07-22 16:11:25
有什么好的工具去探测一个 udp 端口是否存在服务呢？（WIN 下的主机去探测 LINUX 下的 udp/67）
回复于：2005-07-22 16:11:59
引用：原帖由 "我爱钓鱼"]我也发现过一些有趣儿的现象:我把一个用户的IP的input和output全drop了,可是发现他还能上msn和qq,只是不能用上网不能ftp,也有点不理解....
发表：
如果是NAT的话，那只跟FORWARD，PREROUTING链有关。你试试装这些用户的FORWARD跟PREOUTING关掉看看还能不能上
-A PREROUTING -p tcp --dport 1863 -j DROP
-A FORWARD -p tcp --dport 1863 -j DROP
-A FORWARD -p tcp --sport 1863 -j DROP
-A PREROUTING -p tcp --dport 443 -j DROP
-A FORWARD -p tcp --dport 443 -j DROP
-A FORWARD -p tcp --sport 443 -j DROP
-A PREROUTING -p tcp --dport 8000 -j DROP
-A FORWARD -p tcp --dport 8000 -j DROP
-A FORWARD -p tcp --sport 8000 -j DROP
-A PREROUTING -p udp --dport 8000 -j DROP
-A FORWARD -p udp --dport 8000 -j DROP
-A FORWARD -p udp --sport 8000 -j DROP
-A PREROUTING -p udp --dport 4000 -j DROP
-A FORWARD -p udp --dport 4000 -j DROP
-A FORWARD -p udp --sport 4000 -j DROP
回复于：2005-07-22 16:12:27
到华军软件园上随便弄个端口扫描工具就应该可以了
回复于：2005-07-22 16:14:11
引用：原帖由 "mocou" 发表：
如果是NAT的话，那只跟FORWARD，PREROUTING链有关。你试试装这些用户的FORWARD跟PREOUTING关掉看看还能不能上
不知你是否看了前面我做的两个试验？
回复于：2005-07-22 16:15:27
还有，我想看看client做dhcp request的时候，在cmd下用netstat -an看看跟server连接的状态是什么
回复于：2005-07-22 16:15:46
:shock: 看了，我怀疑你RPWT :em02: 哈哈。还有第二个人做了没？
回复于：2005-07-22 16:18:19
引用：原帖由 "bingosek"]还有，我想看看client做dhcp request的时候，在cmd下用netstat -an看看跟server连接的状态是什么
发表：
1、我不确定 udp 是否能通过 netstat 看到连接状态，我认为不可以，因为他不是 tcp
2、整个过程是瞬间完成的
回复于：2005-07-22 16:21:57
引用：原帖由 "platinum"]有什么好的工具去探测一个 udp 端口是否存在服务呢？（WIN 下的主机去探测 LINUX 下的 udp/67）
发表：
nmap -sU
但是好象dhcp服务端的端口扫不到...
回复于：2005-07-22 16:23:00
引用：原帖由 "双眼皮的猪" 发表：
nmap -sU
但是好象dhcp服务端的端口扫不到...
就算能扫到，windows 下也没有 nmap 啊，我前面都说了是 WIN scan LINUX :em17:
回复于：2005-07-22 16:25:08
强烈建议service dhcpd stop
回复于：2005-07-22 16:26:08
win上有nmap,我一直在用呢...
目前用3.81,不过要装winpcap先...
也不知道在xp sp2上是否有效...
回复于：2005-07-22 16:27:46
引用：原帖由 "bingosek"]强烈建议service dhcpd stop
发表：
这个讨论其实没有什么真正的应用价值，就是想搞清楚
我不确定是否因为我的 iptables 有 bug，希望其他人也协助我来做一个测试，看情况是否和我一样
回复于：2005-07-22 16:35:08
引用：原帖由 "platinum" 发表：
这个讨论其实没有什么真正的应用价值，就是想搞清楚
我不确定是否因为我的 iptables 有 bug，希望其他人也协助我来做一个测试，看情况是否和我一样
呵呵，轻松一下，现在想必你也跟我一样头晕脑胀了
回复于：2005-07-22 16:40:25
bingosek 兄如果有兴趣，可以和我一起做一个同样的试验
或者有什么更好的试验方法也可以提出来
我只想知道为什么：）
回复于：2005-07-22 16:48:28
我在单位，没有试验环境
你应该看过http://man.chinaunix.net/network/iptables-tutorial-cn-1.1.19.html#TRAVERSINGOFTABLES
的文章，其中我找到下面一段话：
第二条规则也是解决日志问题，不过问题的产生者变了，这回是外网的DHCP查询。如果你的外网是由非交换的以太网组成的，在那里客户机可以通过DHCP 得到IP地址，也就是说，如果外网里会有很多DHCP查询广播包，那就启用这条规则吧。
你去找一下这条规则怎么写的，应该有些帮助
回复于：2005-07-22 16:54:44
嗯，我有看过
同样的方法，对 DNS 服务（udp/53）是有效的
如果 server 上做 NAT，同时有 DNS 代理，client 的 DNS 指向 server
那么 DROP 掉 udp/53，client 是无法通过解析获得 IP 的
但同样的方法，对 DHCP 无效
回复于：2005-07-22 17:03:42
IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
--destination-port 67:68 -j DROP
IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT
那也就是说在不做nat的dhcp server上就能封住，而在有nat的dhcp server封不住咯？
回复于：2005-07-22 17:05:56
引用：
IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT
那也就是说在不做nat的dhcp server上就能封住，而在有nat的dhcp server封不住咯？
没明白，“在不做nat的dhcp server上就能封住，而在有nat的dhcp server封不住”？
回复于：2005-07-22 17:20:12
的确如此，我做了实验，iptables无法将DHCP的包阻止。
找了找，http://lists.debian.org/debian-firewall/2004/10/msg00159.html
这里也有讨论，没太明白。 :oops:
回复于：2005-07-22 17:26:26
这个问题很有意思
DHCP的东西忘的差不了，我估计和arp有关系，DHCP request发的广播
这个广播的MAC为全１
不用iptables封，而用arptables或者ebtables肯定能封住
回复于：2005-07-22 17:40:54
IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
--destination-port 67:68 -j DROP
IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT
那也就是说在不做nat的dhcp server上就能封住，而在有nat的dhcp server封不住咯？
回复于：2005-07-22 17:41:28
引用：原帖由 "depthblue" 发表：
这个问题很有意思
DHCP的东西忘的差不了，我估计和arp有关系，DHCP request发的广播
这个广播的MAC为全１
不用iptables封，而用arptables或者ebtables肯定能封住
我想到了一点，iptables 是工作在 3 层以上的，而 dhcp 实际上是 2 层的协议，不知是否和这个有关
我现在没条件，我打算再做一次试验试试
首先需要知道 client 的 MAC 地址
iptables -I INPUT -m mac --mac xx:xx:xx:xx:xx:xx -j DROP
然后试试行不行，不知这种方法是否可以匹配到
不过。。。
这种匹配方式比我两个试验里的方法都更严格了，那两种方式都不行，这个能行吗？
有机会再试一下
回复于：2005-07-22 17:46:25
引用：原帖由 "platinum" 发表：
我想到了一点，iptables 是工作在 3 层以上的，而 dhcp 实际上是 2 层的协议，不知是否和这个有关
我现在没条件，我打算再做一次试验试试
首先需要知道 client 的 MAC 地址
iptables -I INPUT -m mac --mac xx..........
我想還是不行的,
因為那是ethernet 廣播,每一個 NIC 都會收到,而 HUB 又沒有管理功能,阻檔不了
因為 packet 不是先經過 iptables , 它有收到,而每台機器也都有收到
回复于：2005-07-22 17:49:44
https://lists.netfilter.org/pipermail/netfilter/2002-May/023826.html
这里就是答案。:-) 我还是贴上来吧.
Derrik Pates touched on this earlier in the thread, but I'll try and
clarify a bit.
The DNCP server of the ISC (Internet Software Consortium,
http://www.isc.org) uses a different type of network access in Linux,
so to speak. Normally, when programs need network access, they open
up an Internet socket of the correct protocol (TCP/UDP), which gets
any packets destined for it and can send packets after the kernel has
applied all IP Tables rules to them. So if you have a policy of
DROP/REJECT or you have a rule that matches a packet to.from this
socket that DROP/REJECTs it, the socket will not receive or be able to
send that packet.
However, the ISC DHCP server uses an Internet Socket of protocol Raw
instead of TCP or UDP. This facility, naturally, is only available to
root (uid 0, really), and receives packets before the IP Tables
processing. It also receives all Internet packet headers as well, so
it gets to do additional processing.
But because Raw sockets get packets before the IP Tables processing,
the ISC DHCP server is able to obtain an IP address through DHCP.
More information (possibly not in a useful state) can be found in the
man pages for socket, ip, tcp, udp,
http://nodevice.com/sections/ManIndex/man1275.html, and, of course,
the source code.
回复于：2005-07-22 17:58:21
收到..还是你能找^_^
回复于：2005-07-22 18:00:50
如果确实是２层的话，用arptables和ebtables绝对不会用问题
2.6的内核支持ebtables，不过最近实在没时间试
回复于：2005-07-22 18:04:23
这个讨论真不错，加入收藏夹 :em06:
谢谢 NetDC，顺便请教一下使用了什么关键字搜到的？ :em04:
回复于：2005-07-22 18:10:12
引用：原帖由 "platinum" 发表：
这个讨论真不错，加入收藏夹 :em06:
谢谢 NetDC，顺便请教一下使用了什么关键字搜到的？ :em04:
google
iptables can not block dhcp
呵呵，下班回家。
回复于：2005-07-22 18:12:07
引用：原帖由 "NetDC" 发表：
google
iptables can not block dhcp
呵呵，下班回家。
找的没你多，难怪找不到 :em10:
回复于：2005-07-22 18:13:38
引用：原帖由 "depthblue" 发表：
如果确实是２层的话，用arptables和ebtables绝对不会用问题
2.6的内核支持ebtables，不过最近实在没时间试
DHCP + HUB 應該還是過澽不掉
還請教 "不有問題" 如何判斷?
ethernet broadcast 欄得下來?
回复于：2005-07-22 18:22:29
引用：原帖由 "abel" 发表：
DHCP + HUB 應該還是過澽不掉
還請教 "不有問題" 如何判斷?
ethernet broadcast 欄得下來?
不论是HUB，还是SWITCH的环境，实际都是一样的，因为SWITHC不隔离广播．ebtables是二层的，甚至可以针对VLAN进行过滤，所以对于arp不会有问题，至于arptables呢，我记得后来就发展成为ebtables了．
arptables很简单，但是ebtables我感觉很复杂，看了很多次很没有真正明白．
说白了，这个实际就是iptables是无法针对２层过滤的．
回复于：2005-07-22 18:28:34
你確定 ethernet 的 packet 一定會先經過 arpfilter/ebtables ?
如果是,那當然沒有問題
但是都用 HUB 接的線,恐怕實情就不是這樣了
因為每台電腦都和 HUB 連,封包是轉送給每台電腦,
你有 arpfilter 有收到,但別人也有收到,
如何過濾呢 ?
NAT 只是個出口,那是茶壺裏的風暴
回复于：2005-07-22 18:35:32
引用：原帖由 "depthblue" 发表：
说白了，这个实际就是iptables是无法针对２层过滤的．
我不这样认为
MAC 地址是存在于 2 层包头里的，IP 包头里是没有的
如果说 iptables 无法针对 2 层过滤的话， -m mac 模块又如何解释呢？
只能说 dhcp 属于 raw socket，优先于 iptables
回复于：2005-07-22 18:40:43
引用：原帖由 "platinum" 发表：
我不这样认为
MAC 地址是存在于 2 层包头里的，IP 包头里是没有的
如果说 iptables 无法针对 2 层过滤的话， -m mac 模块又如何解释呢？
只能说 dhcp 属于 raw socket，优先于 iptables
我的看法是,Client <-->;HUP <--->;DHCP Server , 這個過程跟本不會
經過 NAT Server 上的過濾影響 , 大家都收到 ff:ff:ff:ff:ff:ff
NAT 也收到,但阻礙不了同一個 subnet 內的流通
raw socket 和一般的 socket 沒什麼絕對的不同,只是每個 ethernet 或 ip 層的
欄位你要自己填寫而以, 可以找
http://www.hping.org/hping3.html
來試看看就知道了, 這是 raw socket 最好的工具之一
回复于：2005-07-22 19:00:00
引用：原帖由 "abel" 发表：
你確定 ethernet 的 packet 一定會先經過 arpfilter/ebtables ?
如果是,那當然沒有問題
但是都用 HUB 接的線,恐怕實情就不是這樣了
因為每台電腦都和 HUB 連,封包是轉送給每台電腦,
你有 arpfilter 有收到,但?.........
我印象中是如此的，ebtables和iptables很相似
比如
ebtables -P INPUT DROP
ebtables -A INPUT -p IPv4 -j ACCEPT
ebtables -A INPUT -p ARP -j ACCEPT
ebtables -A INPUT -p LENGTH -j ACCEPT
虽然每个人都会都会收到广播，但是针对要封住到LINUX 服务器DHCP的广播包，是不会有问题的，请求被DROP后，客户端便无法获得IP．
DHCP请求的包，在２层不知道type是多少
回复于：2005-07-22 19:05:00
引用：原帖由 "abel" 发表：
我的看法是,Client <-->;HUP <--->;DHCP Server , 這個過程跟本不會
經過 NAT Server 上的過濾影響 , 大家都收到 ff:ff:ff:ff:ff:ff
我的意思不是用 NAT 去过滤广播，过滤是做在 dhcp server 上的
看了 NetDC 贴的文档后，得知 raw socket 在 iptables 处理前先被 dhcp server 处理
回复于：2005-07-22 19:11:06
我前面的觀點...一個重點 , 這是茶壺裏的風暴
PC3
|
INTERNET --- NAT ---HUB ----PC1
|
PC2
我相信 platinum 兄在經費問題下,架構應是這樣的
假設 PC1 enable 了 DHCP , PC2 是要 IP 的, 你的 filter 在那裏 ?
照platinum兄前面的描述,定是在 NAT 這個點上
這個點如何欄到 PC1 PC2 間的溝通呢 ?
HUB 會把封包無條件轉過去(即使 PC1 單純和 PC2 互連也會轉過去,形成如同廣播), 即使你 NAT run 什麼 filter 都沒有用,不是嗎 ?
回复于：2005-07-22 19:12:00
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
看看这个，是否有帮助
直接在DHCP SERVER过滤广播
下周有时间试试
回复于：2005-07-22 19:14:44
引用：原帖由 "platinum" 发表：
我的意思不是用 NAT 去过滤广播，过滤是做在 dhcp server 上的
看了 NetDC 贴的文档后，得知 raw socket 在 iptables 处理前先被 dhcp server 处理
?
不是這個意思 ?
引用：环境：一个宿舍楼层，一台 Linux 做 NAT，带十几台电脑，一个普通HUB，大家集资购买
因为网络中有非法 DHCP 服务器，影响了大家正常 IP 分配（估计是有人用VMWARE），我想了一个方法来找出那个电脑
代码:
[root@platinum root]# tcpdump -e -i eth1 -nn port 67 -c 4 2>;&1|awk '/bootp/{print $2" -->; "$3}'
0:a:e6:a9:64:a2 -->; ff:ff:ff:ff:ff:ff
0:e0:4c:39:6d:96 -->; 0:a:e6:a9:64:a2
0:a:e6:a9:64:a2 -->; ff:ff:ff:ff:ff:ff
0:e0:4c:39:6d:96 -->; 0:a:e6:a9:64:a2
[root@platium root]#
原理是听包，找到那个电脑的 MAC，因为 IP 一般人都会改的，MAC 不一定
用这个方法找出他的 MAC，然后在 NAT 机器上面禁止掉他
前提：因为资金问题，不能购买带管理的交换，因此仅从技术方面分析，帮助那些无助的朋友们分析解决问题
有台 PC 跑出了 dhcp ? 要 filter 它 ?
回复于：2005-07-22 19:18:38
哦，abel 兄，开始是想如何找出那个非法 dhcp server
后来问题衍变为
合法 dhcp server（linux） 上的 iptables 无法过滤掉其他 PC 的 dhcp client 请求
我们说的不是一码事 :em06:
回复于：2005-07-22 19:36:57
引用：原帖由 "platinum" 发表：
哦，abel 兄，开始是想如何找出那个非法 dhcp server
后来问题衍变为
合法 dhcp server（linux） 上的 iptables 无法过滤掉其他 PC 的 dhcp client 请求
我们说的不是一码事 :em06:
哦~soga,那我就離題了
那就要濾第二層東西了,如 depthblue 所言, iptables 是濾第三層的, 至於 -mac 也是只濾第三層中的mac , 至於 raw socket 問題,不可能說它是 raw socket 就可以過去,
而是這個 raw socket 是開發在層次不同的地方
回复于：2005-07-22 19:44:14
引用：原帖由 "abel" 发表：
哦~soga,那我就離題了
那就要濾第二層東西了,如 depthblue 所言, iptables 是濾第三層的, 至於 -mac 也是只濾第三層中的mac , 至於 raw socket 問題,不可能說它是 raw socket 就可以過去,
而是這個 raw socket 是..........
abel 兄急得直说日语啦 :em06:
言归正传，abel 兄说“至於 -mac 也是只濾第三層中的mac”，我并不是很赞同
IP 数据报中没有 MAC 这个信息，二层里倒是有
如果说 iptables 能过滤 MAC，那么按道理来说
iptables -I INPUT -m mac --mac $CLIENT-MAC -j DROP
这样应该就可以阻止某个 client 过来的 DHCPREQUEST 了才对，今天晚上我试验一下
回复于：2005-07-22 20:06:19
刚才又查了一些资料，应该是这样的
很多操作系统在实现网络部份应用的时候只实现了一些常用的协议：如icmp,udp,tcp
而其它协议如：ospf等在操作系统上并没有实现，此时借助raw socke。将这个包交给raw socket.
也就是说并不是所有IP包都要通过系统核心过滤的 :em03: :em03: :em03:
回复于：2005-07-22 20:32:57
引用：言归正传，abel 兄说“至於 -mac 也是只濾第三層中的mac”，我并不是很赞同
嗯~你誤會我的意思了,
我是指 IP 層中,其下的 MAC 部份
也就是你說的意思.
也就是 iptables 過濾的是符合 IP 層中的 mac
回复于：2005-07-23 16:23:02
我这样说不知道有没有问题：
irc版本的dhcp程序处理dhcp request时是不经过iptables，所以无论iptables怎么设置都不会影响irc版本的dhcp，这是irc版本的dhcp工作原理决定的
回复于：2005-07-24 16:09:39
引用：原帖由 "platinum" 发表：
abel 兄急得直说日语啦 :em06:
言归正传，abel 兄说“至於 -mac 也是只濾第三層中的mac”，我并不是很赞同
IP 数据报中没有 MAC 这个信息，二层里倒是有
如果说 iptables 能过滤 MAC，那么按道理来说
iptabl..........
这个应该没有用的。
我的dhcp server IPTABLES设置的规则是
iptables -P INPUT DROP
然后是ip对应mac允许进入。
在这么严的规则之下，仍然不影响我的dhcp server的IP分配。
这个也就是说，如果有人在网内开dhcp服务器的话，你几乎没有能力来防止他捣乱，这个我觉得比较恐怖。
回复于：2005-07-26 16:38:07
http://comm.ccidnet.com/pub/article/c1716_a198775_p1.html
这里说到的win2000提供DHCP认证功能是怎么回事呢？
回复于：2005-07-26 20:47:22
引用：原帖由 "platinum" 发表：
abel 兄急得直说日语啦 :em06:
言归正传，abel 兄说“至於 -mac 也是只濾第三層中的mac”，我并不是很赞同
IP 数据报中没有 MAC 这个信息，二层里倒是有
如果说 iptables 能过滤 MAC，那么按道理来说
iptabl..........
platinum 老大这里确实理解有问题，ip数据报不可能没有mac信息
二层数据报：
frameheader---framebody
三层数据报：
frameheader---ipheader---ipbody
对于工作在二层的设备来说任何数据报都只区分为数据头和数据体，一个ip包的ip头和ip数据会被统一认作二层数据体。
而对于工作在三层的设备来说，基本上是二层已经根据二层头作过相应处理提交上来的，但你不能说它没有二层头，这个信息肯定是保留的，只是对于三层设备来说只能拿到二层设备已经分拣过的数据。
iptables确实是工作在三层及以上，这从iptables几个钩子函数的位置可以看出。有了这个结论，再澄清两点：
1，关于iptables的mac过滤----虽然工作在三层，但是二层信息也是存在的，所以过滤也是可行的，但有一点限制，就是二层向三层递交时，只会递交你能对应识别的三层包：
（1）iptables是工作在第三层ip协议下，你iptables当然不可能抓到其他三层协议的数据报，比如，你无法处理ipx包。
（2）iptables是工作在第三层ip协议下，不能处理二层没有提交到三层的数据报，比如arp请求和rarp请求，你是过滤不到的。
2，关于为什么iptables无法过滤dhcp请求----根据第一点的结论，这一点也很显然可以得出结论了：
（1）dhcp协议是一个ip地址分配协议，面向的是还没有建立ip协议盏的client，对于此类的client，很显然不可能使用目前还不存在的三层协议通讯来分配三层地址。
（2）由（1）的结论以及rfc可知，dhcp是通过二层广播来传送报文的，所以共享hub环境和交换环境的广播处理的不同导致的不同的结果。
（3）根据（2），此时的dhcp报文，对于dhcpserver来说，不可能提交到ip层，所以不经iptables处理，对于dhcpclient，ip协议盏还没建立起来，你iptables都还没出生，你还能干什么？
所以对于dhcp，只能从二层环境想办法，iptables就别想了，ebtables应该还可以有所作为，再加上交换环境和共享环境的不同，相信也能得出自己相应的解决办法了。
再有就是Windows的验证dhcp问题，这个是因为Windows特有的AD构建的特有的安全边界导致的，你可以看一下，所谓的验证dhcp服务器，只能用于域存在的环境，如果在同一网段即存在域和工作做，那恶意dhcp服务器对于工作组环境的机器还是会起作用的。
表达能力不强，见谅！
回复于：2005-07-26 20:50:28
再补充一点，关于rfc提到的udp端口问题，既然用到端口了，那已经上升到4层协议了，你觉得一个三层地址的分配可能会通过四层协议来完成吗？
答案是：这个四层通讯是客户和服务器协商ip租约以及续租ip的，跟ip初始无关。
回复于：2005-07-26 21:08:36
晕。你说的iptables到底工作在哪一层呀，端口是在四层上？
回复于：2005-07-26 21:26:34
引用：原帖由 "colddawn" 发表：
platinum 老大这里确实理解有问题，ip数据报不可能没有mac信息
二层数据报：
frameheader---framebody
三层数据报：
frameheader---ipheader---ipbody
对于工作在二层的设备来说任何数据报都只区分为数?.........
我认为我没有错，相反我倒认为 colddawn 兄说的不太正确
下面我贴几个图出来证明一下我的观点
|
