有谁知道什么决定了ARP路由器将尝试的数量？ 我有两个设备有不同的行为，如果我尝试跟踪路由到属于路由器上的一个接口的子网上不存在的主机，一个Linux的盒子将尝试ARP响3次，然后返回一个主机不可达的icmp消息。 Junos会连续尝试arp而不返回任何东西。 是否有一个sysctl值决定这个或任何东西。
我正在使用iptables在主机上设置防火墙。 我想禁用时间戳ICMP请求，但它是有线的，我只允许types8（回声请求）进入主机，但事件仍然可以从我的主机得到时间戳 64 bytes from xxxxxxxxx: icmp_seq=2 ttl=61 time=2.56 ms TS: 36654775 absolute -6423 3 1 -4 0 4 0 -2 Unrecorded hops: 1 我试图只允许types8，但它不起作用，看来我所能做的就是让所有的ICMP请求通过，或拒绝所有的，下面是我使用的configuration脚本。 iptables -F iptables -X iptables -Z iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state […]
我正在创build一个Tracert程序，并且想知道在Ping有效载荷中使用的值“buffer”是否真的很重要。 它可以是任何东西，或路由器根据缓冲区的内容作出不同的响应？ 那么ICMP ping消息的其他部分呢？ 不要片段等… http://msdn.microsoft.com/en-us/library/ms144962.aspx 我发现一个样本设置缓冲区如下所示： byte[] Buffer { get { if (_buffer == null) { _buffer = new byte[32]; for (int i = 0; i < Buffer.Length; i++) { _buffer[i] = 0x65; } } return _buffer; } }
在Wireshark中，如果我想写一个只接受ICMP目标不可达（types3）消息的filter，则filter为icmp[0] == 3 。 在这种情况下，如何计算0的数据包偏移量？ 编辑 基于维基百科的上述图像，ICMPtypes在0-7位之下。 所以它是第一个字节，因此是0？
我有以下规则，我相信将限制icmp数据包到1 / s。 :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [7:988] -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -m icmp –icmp-type any -m limit –limit 1/sec -j ACCEPT -A INPUT -s 11.xx71/32 -p tcp -m tcp –dport 22 -j ACCEPT -A INPUT -s 11.xx65/32 -p tcp -m tcp –dport 22 -j […]
我有一个networking设置如图所示： 中央盒子是一个网关（Ubuntu 15.10），用于中继各种networking（图片上只显示一个 – lan0 ）和互联网之间的数据包。 网关：我可以ping通互联网上的所有接口和主机 laptop ：除了192.168.0.254之外，我可以ping通互联网上的所有接口和主机 我不知道为什么我不能ping通，这就是为什么我抓住了交通。 这不是我的问题，但如果有人有一个想法，这是值得欢迎的。 所有接口都接受所有stream量，并且所有接口之间都有转发 当捕获数据包以了解ping失败的原因时，我做了三个testing 从laptop ping到192.168.0.10 ping 通过 ，但tcpdump -i int0 icmp不显示捕获的任何数据包 从laptop ping到192.168.0.254 ping不通过和tcpdump -i int0 icmp显示 13:26:28.032635 IP 10.10.10.93 > 192.168.0.254: ICMP echo request, id 1, seq 671, length 40 13:26:32.604606 IP 10.10.10.93 > 192.168.0.254: ICMP echo request, id 1, seq 672, length 40 […]
所以，我们最近从LIR获得了我们的/ 48前缀，并开始小规模部署在实验室中。 让我感到奇怪的是http://ipv6-test.com/这样的网站坚持允许传入的ICMP Echo请求。 我明白为什么你应该允许ICMPv6传出，但传入？ 即使这只是一个平？ 所以，我的问题是：除了可能的利用ICMP的DDoS攻击，在允许传入的ICMP回应请求方面是否有缺点？ 我读了RFC4890（ https://www.ietf.org/rfc/rfc4890.txt ），但在那里找不到明确的答案。 A.5。 ICMPv6回声请求和回声响应 build议 没有人认为在精心devise的IPv6networking上扫描攻击存在很大的风险（见第3.2节），因此默认情况下应该允许连接检查。 鉴于RFC已经快10年了，这一点仍然有效吗？ 此外，RFC不区分传出和传入方向。 我总是觉得v4的build议是在网关处阻止ICMP，但是v6又一次严重依赖于ICMP。 那么，有什么build议？
我有一个简单的freebsd 9.0机器，但每次我启动我的freebsd和使用命令dmesg。 没有任何硬件信息，但充满了 "Limiting icmp unreach response from 1293 to 200 packets/sec" 那里。 有没有人可以告诉我为什么会发生这种情况？ 而我怎么能抹去这个？
即使跑完了 iptables -A INPUT -p icmp -m icmp –icmp-type 3 -j DROP 我一直在tcpdump上获取ICMPtypes3的代码13数据包。 当我运行tcpdump icmp ，我收到如下消息： 19:41:31.923630 IP NAMESOURCE > MY_NAME: ICMP net IP_SOURCE unreachable, length 76 我的问题是，我怎样才能摆脱这个数据包？ 顺便说一句，我从多个来源得到这个数据包，这导致我认为这可能是某种（D）DoS。 但我不确定我在这个angular色上扮演着什么angular色。 此外，snort不断发出警报： [**] [1:485:4] ICMP Destination Unreachable Communication Administratively Prohibited [**] [Classification: Misc activity] [Priority: 3] 05/02-19:44:20.171298 SOURCE_IP -> MY_IP ICMP TTL:238 TOS:0x0 ID:13584 IpLen:20 DgmLen:56 […]
这是否有安全原因？