Cloud Native应用交付
  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
☁️We are in new App Mesh era: imesh.club ☁️
  1. 首页
  2. 网站技术
  3. 正文

ARP病毒开始危害在IDC中!

2007年01月10日 4157点热度 0人点赞 0条评论
2天一夜从西安到北京又从北京回了西安 ,回来上网就发现西安EINIT群中通网网站的公告。走之前就听通网的朋友在群里说过,通网朋友的测试证明数据在跨越网关后确实出了问题,表面看确实很像路由器出了问题。但是仔细分析下,这个说法靠不住。

 首先,如果是路由器漏洞导致的,我想对于路由器的漏洞其本身就是个高级的网络漏洞,能有能力控制到电信路由器的人估计还不屑于这么目的明显得插入一段网站的iframe代码。能有这样能力的人要么不攻击,要么就是大攻击。

其次,如果是路由器漏洞,发生这样的情况,电信的人早都该全力以赴去解决问题了,因为往往路由器的漏洞是同时存在多个路由系列型号上的,如果IDC的路由器出了问题,那么可能很多地方的路由器都要有这问题!这是什么概念?可能有一天所有人上网都会发现访问任何东西都有问题了。这可就是严重的事故和灾难了!要是这样还不引起警惕,估计电信明天就该倒闭了。

最后从路由技术角度说,路由器的主要功能只是给数据包进行路径寻址,说给数据加入一段代码,这个好难,传输过程中的数据包是被分片的,传输过程中牵涉到分段,重组,校验等诸多问题,特别是校验,如果在发出端被强制加入数据,那么接收端在做TCP的CRC时肯定要报错。要给某几个网站的网页的内容插上一段代码简直是难上又难,能这样插入代码的功能一般都是7层设备或者说是CB(content basic)设备,没有接触过很高端的设备,目前我还不知道到底有没有这样高级功能的路由器(12000的支持吗?),而一般的IDC机房是不会部署这样高端的设备。

所以说,如果是路由器漏洞导致的问题这个站不住脚,但是为什么又会表现出通过路由器就有问题呢 ?
这个我想说,上次我在EINIT问过大家一些IP问题,大家好像不是很感兴趣,这个问题就可以通过解释在以太网中数据传输的原理来解释,大家都知道通过IP协议通信需要IP地址,但是其实在一个以太网中最终通信不是靠IP地址而是MAC地址,计算机通过ARP协议将IP解释为MAC,计算机中最后保存的就是IP和MAC的对应关系。当一个数据在同一网段通讯时候,数据是不通过网关的,计算机直接通过MAC将数据递交给对方,而数据一旦要跨网段,就要通过网关,这里网关就是路由器了,玄机就在这样,如果此时有个中间人攻击的话,问题就来了,服务器上保存着网关IP和网关接口的MAC,如果这个对应关系不正确的话,就会出现问题,此时有个中间人突然冒充路由器出来说话:它在LAN中喊叫它是网关。这样,网内所有机器都认为网关是这个中间人了,于是所有和真实网关的数据通信都先发给了这个中间人,中间人处理数据,然后将处理后的数据交给真正的网关路由器。从而实现了攻击。

其实这个问题是ARP协议本身缺陷造成的,在很多LAN中都可能有过这样的经历,只不过当它危害的是一个服务器的网段时候,其危害就被放大了。

IDC有很多方法解决这个问题,这个姑且不说,因为那么看IDC人的脸色,自己能做的就是在自己服务器中用arp -a来查看当前网关IP对应当是不是真实网关MAC,真实的网关MAC要在没问题的时候就注意看,或者咨询IDC,也或者大概判断:CISCO的MAC开头是0004,0012。。好像CISCO开头的好几个~~,华为的MAC开头是:(华为的设备给拿走了,有机会补上)

 解决方法:1。自己在服务器上静态邦定网关,arp -s ip mac,注意先获得正确的网关MAC
                      2。自己在服务器上装一个防ARP病毒的软件,好像有个叫 antiarp的吧,用这个软件可以扫扫网内哪个服务器有问题。
后记:
在网上搜了艘,好象好多网站托管的服务器都遇到这个问题,连51.la统计网站都被这样强奸了 我汗~~~危害真大
本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: 暂无
最后更新:2007年01月10日

纳米

http://linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

取消回复

纳米

http://linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 分类目录
    • Avi Networks (3)
    • Cisco ACI (1)
    • CISCO资源 (21)
    • F5 with ELK (8)
    • F5-Tech tips (38)
    • F5技术 (203)
    • Juniper (4)
    • Linux (7)
    • Nginx (18)
    • SDN (4)
    • ServiceMesh (19)
    • WEB编程 (8)
    • WINDOWS相关 (7)
    • 业界文章 (18)
    • 交换机技术 (20)
    • 化云为雨/Openstack (35)
    • 协议原理 (52)
    • 容器/k8s (64)
    • 我的工作 (19)
    • 我的生活 (70)
    • 网站技术 (19)
    • 路由器技术 (80)
    • 项目案例 (28)
    文章归档
    标签聚合
    F5 k8s openstack nginx istio DNS envoy gtm docker network flannel api irule bigip neutron cc kubernetes ELK vxlan BGP dhcp VPN IPSec lbaas ingress ingress controller nginx plus sidecar IPSec VPN NAT sql
    最新 热点 随机
    最新 热点 随机
    Say hello for 2021 二进制flannel部署,非cni网络模式下与k8s CIS结合方案 又是一年国庆 Service Account Token Volume Projection Istio ingressgateway 静态TLS证书加载与SDS发现方式配置区别 Istio里Gateway的port定义与实际ingressgateway的listener端口关系及规则 Helm 3 部署NGINX Ingress Controller 应用交付老兵眼中的Envoy, 云原生时代下的思考 Istio sidecar iptables以及流量控制分析 Istio 熔断策略及envoy配置
    Say hello for 2021
    Cisco 2800 Series Integrated Services Routers Configuration Examples and TechNotes [学习笔记]OSPF学习总结 双工问题 PPPoE实例:2600路由器接ADSL Modem(图) JNCIA-ER 考试学习笔记 [一个有意思的问题]关于vlan的 NAT - Ability to Use Route Maps with Static Translations [转贴]拿到CCIE证书两年后! 最新BIND漏洞CVE-2015-5986 and CVE-2015-5722对F5的影响 Docker学习备忘1
    链接表
    • Jimmy Song‘s Blog
    • SDNap
    • SDNlab
    • SDN论坛
    • Service Mesh社区
    • 三斗室
    • 个人profile

    COPYRIGHT © 2020 Cloud Native应用交付. ALL RIGHTS RESERVED.

    THEME KRATOS MADE BY VTROIS

    京ICP备14048088号-1

    京公网安备 11010502041506号

    [ Placeholder content for popup link ] WordPress Download Manager - Best Download Management Plugin