• 由于PADT伪造攻击带来的大面积掉线原因分析


    今天一早接到一个客户电话,说他有一个交换机下面的用户,大面积和上线下线。

    由于之有已建议用户在主干换了普通VLAN交换机。所以这次出现问题概率较小,只在一条支路的交换机下面。

    下面我对这个情况的发生做一下分析:

    PPPoE认证分为两个阶段:

    第一阶段:发现阶段

        1.客户端以向FFFF-FFFF-FFFF广播发送PADI数据包寻找AC,即服务端

        2.服务端回复一个PADO单播帧;

        3.农牧民端回复一个PADR单播请求,期望进行会话

        4.服务端回复一个PADS数据包,同意进行下一步协商(包中携带一个sessionid,作为用户的凭证之一)          

    第二阶断:会话阶段

        双方使用PPP的LCP协议协商链路,NCP进行用户名密码检验,双方完成通讯。     

        在第一阶段pppoe会话重要依据就是双方的mac地址,在和sessionid  

        在用户下线的时候,用户会发送PADT数据包进行协商,断开会话连接

    大家可以想象一下:病毒模拟发包的方式,向服务端发送PADT数据包?服务端以为是客户端请求下线,就会断开客户端,导致客户端掉线,多可怕的事啊。

    具体数据包看附图

    有人要问了,病毒没有客户端与服务端通讯的seddionid,如何断开?这个问题,我晚点再给大家解释,大家先看图

    图上第一段是客户机正常下线的数据图片。

    过程是客户端向服务端发送一个PADT,然后服务端收到PADT包,然后再回馈一个PADT包,客户端下线,这个过程服务端只收到一个PADT数据包的。

    图上第三段是大面积掉线用户的数据图片。

    大家仔细看,服务端收到两个PADT包,多了一个PADT?这要如何解释?

    原因是病毒模拟客户端向服务端发送PADT,服务端回馈一个PADT,此时按理如果是由客户端自己主动发起的断开,他是不会再回馈一个PADT包的。

    可是我们服务端确实是收到了两个PADT,这是因为第一个不是我们的客户端发送的(是病毒发送的),所以客户端以为是服务端主动断开,所以再回复一个PADT,才有上面的2个PADT包。

    我仔细看了一下日志,大部分用户都是2个PADT的数据包,印证了这一点。

    接下去,我向大家解释一下,为什么没有sessionid,病毒为什么能模仿发送数据包

    发送PADT起码要知道客户端MAC和sessionid,我在抓包的时候发现:中毒的客户机,一秒钟发起5000多个ARP请求,而且是获取其他客户机MAC地址的ARP数据包。

    这说明病毒一直在扫描内网的MAC,这个因为是二层通讯,这人以很简单可以获取的,而且在三层是禁止不了的。

    接下去说一下sessionid吧

    由于session是0xFFFF,也就是65536,网上有人说,病毒要断开一个客户端,要发送65536个数据包?

    其实不然的,病毒没有这么傻吧?断开一个客户端,要这么麻烦,6万多个数据包,也得发送好一会儿。

    病毒其实可以模拟一个pppoe认证过程的,自己就会获取一个sessionid,或者根本不需要,因为本身就是pppoe 上网的,直接获取。

    大家都清楚,PPPOE的sessionid是累加的,这个看日志就知道了,所以病毒只要往他的MAC地址库里面取出来的地址(这个数量就很少了吧),然后发送session为当前sessionid的数值就可以了

    想想,是不是太可怕了?

    又有人要问了,这样之前上网的不就没事?确实是,但是你总要下线吧,下线后,你的sessionid就在病毒扫描范围内了,有甚者,全网扫描

    有人要问了,这个要怎么防呢?其实这是二层通讯,除非你每个端口用VLAN隔离,才可以完全避免啊,

    其实只要增加VLAN交换机使用,8口的才50多一个,以后还会更便宜,出了问题,影响的面积就不会是全网,不但有些用户不受影响,而且也好找

    如果有遇到这个问题要咨询详细处理的,可以加我的Q561454825

  • 相关阅读:
    CAD中的各种Polyline
    在CAD二次开发中使用状态条按钮
    在CAD二次开发中使用进度条
    EXSI6.5复制文件太慢的解决方法
    vlan交换机的端口模式有哪几种
    此计算机上的安全设置禁止访问其他域的数据源
    Could not write to output file 'c:WindowsMicrosoft.NET ASP.NET Filesxx' -- 'Access is denied
    添加现有文件夹到项目解决方案
    SSM-MyBatis-18:Mybatis中二级缓存和第三方Ehcache配置
    SSM-MyBatis-17:Mybatis中一级缓存(主要是一级缓存存在性的证明,增删改对一级缓存会造成什么影响)
  • 原文地址:https://www.cnblogs.com/lome/p/4231720.html
Copyright © 2020-2023  润新知