今天早上，我发现我们的域名和子域名在4.2.2和4.2.2.1 DNS服务器以及其他我认为是中毒的，尽pipe我还没有确认其他域名。 使用OpenDNSparsing正常工作。 我已经更新了我们的本地DNS服务器，并清除了内部已修复内容的caching。 问题在于，该领域是面向公众的，客户也有问题。 我们是域名的权威DNS服务器，所有这一切都在我们的控制之下。 我不知道该怎么做的是修复名称服务器不受我们的控制。 我们能做些什么来达到目的？ 目前我唯一能想到的解决方法是要求客户把他们的DNS改为OpenDNS，这是不实际的。 另一个解决方法是改变我们的TLD，这是不太实际的。
有一个可靠的方法来拒绝带有欺骗性电子邮件地址的邮件吗？ postfix在传入的邮件上正常运行什么样的检查？ postfix是否默认检查反向dns？ postfix有没有其他的内置和默认激活检查？ 什么样的filter/ milters是有用的，以防止接受欺骗邮件？ 感谢您的帮助。
我正在尝试在ebtables中创buildIP-MAC配对规则。 有几个教程和相关的问题[1]可用，但我有一种具体的设置。 环境：我有很多物理主机 。 每个主机都有几个以太网卡，join了债券，并用作桥的奴隶。 每台主机上有许多虚拟机（kvm，qemu，libvirt）。 每个虚拟机都通过称为vnet [0-9] +的新端口连接到其物理主机的网桥。 没有NAT。 networking工作正常，所有的物理主机都可以ping通，所有的虚拟机也是如此。 每个虚拟机都有自己的IP地址和MAC地址。 问题：在虚拟机内部，可以将IP地址更改为另一个IP地址。 find解决scheme：在ebtables网站上有已知的解决scheme[2]，但是这种解决scheme适用于仅使用一台主机的情况。 它允许所有stream量，并且如果存在来自IP的数据包与不允许的另一个MAC，则数据包将被丢弃。 如果有多个主机，则需要在所有主机上注册所有现有的IP-MAC对。 需要反向策略解决scheme。 已开发的解决scheme：我试图以倒置的方式使用ebtables。 这是我尝试的一个例子。 例1 Bridge table: filter Bridge chain: INPUT, entries: 2, policy: DROP -i bond0 -j ACCEPT -p IPv4 -s 54:52:0:98:d7:b6 –ip-src 192.168.11.122 -j ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: […]
在我正在build设的网站上，我计划logging提交的IP地址，以防万一是必要的。 我不介意代理，但彻底欺骗你的IP地址将打败目的。 要执行完整的GET操作，（不pipe您是否收到或是否通过）都是一个合法的IP地址？ 或者一个网站被垃圾邮件从随机欺骗IP地址的post？ （POST有什么不同？）
我正在阅读关于Google新的公共DNS服务的一些说明： 性能优势 安全优势 我注意到这一段的安全部分： 直到标准的系统范围的DNS漏洞解决scheme普遍实施（如DNSSEC2协议），开放的DNSparsing器需要独立采取一些措施来减轻已知的威胁。 已经提出了许多技术; 请参阅IETF RFC 4542：使DNS更加适应虚构应答的措施 ，其中大部分概述。 在Google Public DNS中，我们已经实施了以下方法，并build议您采取以下措施： 过度configuration机器资源以防止对parsing器本身造成直接的DoS攻击。 由于IP地址对于攻击者来说是微不足道的，所以不可能阻止基于IP地址或子网的查询。 处理这种攻击的唯一有效方法是简单地吸收负载。 这是令人沮丧的认识; 即使在堆栈溢出/服务器故障/超级用户，我们经常使用IP地址作为各种禁止和阻止的基础。 认为一个“天赋”的攻击者可以轻易地使用任何他们想要的IP地址，并合成尽可能多的独特的假IP地址，是非常可怕的！ 所以我的问题是： 攻击者在野外伪造IP地址真的很容易吗？ 如果是这样，可能有哪些缓解措施？