翻译：pwn_361
预估稿费：260RMB（不服你也来投稿啊！）
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
根据纵深防御的概念，一个保护重要服务的多层安全架构，在信息技术领域具有重要地位。基于此，在建设企业网络时，关键系统不能与其他系统在同一网络中。在这篇文章中，我们将结合实例，分析通过使用双网卡的跳板主机，攻击者如何无障碍的访问内部其他网络。
什么是路由？
确定不同网络中的设备如何相互通信的过程称为路由。通常由路由器来执行具体操作。路由器通过路由表将不同的数据包发送到各自的目的地。当然，路由功能不仅可以在设备中实现，比如路由器，也可以安装在操作系统中，在电脑中实现。
根据上图中的例子，为了在192.168.1.0/24和192.168.10.0/24两个网络之间进行通信，就需要一个路由表。根据路由器里面定义好的规则，数据需要从192.168.1.0/24源网络发到192.168.10.0/24目的网络中去。
网络数据包会经历如下过程：
1.这个IP地址是否在本地网络中？
如果在，直接发过去，如果不在，将数据包发送到网关。
2.当路由器收到数据包，首先查看自己的路由表
我有目的IP地址或目的网络的路由规则吗？如果有，将这个数据包路由到目的地址。如果没有，发送到下一网关。
3.其它的路由器重复同样的过程
4.数据包最后到达的路由器负责数据包退出互联网机制。
什么是双网卡中转跳板主机？
通常，在正常访问网络的过程中，通过已经被攻破的计算机，有些网络我们也不容易进去。如果已经控制的计算机连接着多个网络，那么网络隔离就没有什么用，因为如果控制了这个主机，把这个主机做为跳板，就可以横跨多个网络，只要有这个中转跳板，各种防护方法，都形同虚设。通过这种双网卡中转跳板方式，攻击者在受影响的系统上执行路由，就可以访问到隐藏的网络。对新发现的网络的每一个请求都通过这个数据中转跳板来传输，这就像是一个隧道。
如上图，有一个设备有两个网卡，能同时访问到192.168.1.0/24和192.168.10.0/24两个网络。在正常情况下，这两个网络之间没有访问权限，除非定义了路由规则。根据这种结构，这个双网卡的用户，能访问到在DMZ区的一些服务。
攻破第一个数据中转跳板主机(双网卡主机)
根据我们的攻击方案，我们首先攻破了RD系统，并返回了meterpreter SHELL ，同时RD能连接到DMZ区。
然后，我们通过信息收集，确定了RD系统有两个网卡。如下图所示：
攻击者已经获得了RD系统的权限，下一步用第二个网卡，攻击7.7.7.0/24网络。当然，对于攻击者，首先需要在RD上定义路由规则。
在Metasploit里，这非常简单。通过当前的meterpreter会话，输入下面的命令，就可以创建路由规则。
根据定义的路由规则，只要ID是2的meterpreter会话一直在运行，攻击者在Metasploit 框架中，就可以访问到7.7.7.0/24网络。
然后，用一些后渗透模块，如arp_scanner，扫描7.7.7.0/24网络中的存活主机，发现了7.7.7.0/24网络中存在多个存活主机。
危险！安全人员和开发运维人员之间的误解 阅读原文»
安全团队和开发运维人员团队之间的误解可将企业置于业务风险之中
从物理、金融风险，再到战略和运营风险，今日企业被种种风险所包围。企业和员工必须就这些风险进行沟通，这反而会促进企业团结一心。这种沟通需要IT人员、安全人员和开发运维人员(DevOps)的通力合作。这些团队应当清晰地认识到应用的安全性和业务风险波动之间的关联，这会让他们进一步明了自身在解决安全风险时的职责。相对的，失败的沟通也会让整个企业处于危险之中。
倾向于聘请开发运维人员的企业通常会追求高投入产出比、内部的持续创新，以及高敏感度的客户响应能力。大多数领导团队最恐惧的就是对手的创新和进步，以及疏远了本应抓住的客户而导致销售额损失。因此，安全团队的话语权远远不如开发运维团队，更不要说阻止后者了。即使在最理想的情况下，安全团队也只能对他们产生一些影响。
安全团队要想和商户以及开发运维人员进行有效沟通，就需要了解应用安全和企业面临的风险波动之间的关联。如果能实现这一目标，安全团队将会在信息风险事宜上更有话语权。然而，如果对这些风险置若罔闻，企业将会遭受各种安全问题的困扰，团队地位也会一落千丈。
避免沟通失败的第一步，就是了解开发团队不需要的安全措施。某些最佳实践指南就不尊重技术现实，比如"加密数据库中所有数据"，这样的指南显然不具备实际意义。标准应该适合应用，并且对于开发团队具有可行性。那些缺乏开发经验的安全团队常常误入这个陷阱。
除此以外，执行安全测试时漏洞信息管理的欠缺是害处多多的。检测工具会误报，虽然确定了这些漏洞，但是这些"漏洞"不能反映系统或软件的真正弱点。工具还会错报所检测到漏洞的严重程度，而导致的不合理优先级。在与开发运维团队沟通时，漏洞误报既浪费时间，也降低了安全团队的可信度。
最好的结果是：对缺乏兼容性的漏洞加以沟通，或形成未修复漏洞的日志。最坏的结果是：开发团队把时间浪费在了没用的补丁上。应用的安全性常常难以捉摸，所以许多开发团队仅凭自身是难以理解漏洞的。如果他们无法认识到这些内容，他们就无法正确评估漏洞的风险，也不会知道该如何解决它们。而兼容和支持恰恰是开发团队取得成功的关键。
开发运维团队需要和安全团队沟通哪些内容?
当安全团队与开发者沟通漏洞时，漏洞必须确实存在且被精确测评，安全团队对漏洞影响的说明会让开发运维团队更加心中有数。针对性的补救建议至关重要，它需要尽可能和开发团队所使用的语言和框架相符。这使它能更容易解决问题，漏洞可以更快也更有效地被修复，修复漏洞的时间产出比也会得以改善。目标明确的漏洞修复也更容易一次性成功。
安全团队还可以为漏洞的处理以及合规提供有价值的指导。一旦因为漏洞而导致处罚或关停服务，开发团队需要及时获得这些漏洞信息并第一时间进行修正。
除了漏洞，安全团队还可以就系统架构建议进行进一步沟通，来更好的设计应用以减少系统因为合规要求而受到的种种束缚。举例而言，将信用卡相关事宜交给可信的第三方可以避免系统需要受不符合PCI-DSS的评估。另一个例子，不进行非必要的个人身份信息存储（PII）以避免人工管理数据的风险。营销人员经常想要存储所有可访问的数据，但是系统设计师需要理解储存过多的数据对隐私和安全的影响以及相伴的风险。
安全团队和开发运维团队之间的误解会让企业面临风险。在与业务风险相关的应用安全已经对业务造成了影响时，安全团队应当出面进行沟通。如果安全团队可以从品牌、金融、战略等方面进行风险评估，那么他们就会成为开发运维团队最可靠的谏言者，并帮助开发运维团队建立和维护安全的系统。
相关阅读
黑客技术官网地址：http://www.hackdig.com/
没有评论:
发表评论