WEB服务器为什么取不到用户的MAC地址

引言

起因是某个同事接到了领导安排下来的一个需求,要在一个Web应用(Java+Tomcat)中,记录用户登录时的IP地址和MAC地址,用于安全审计,于是咨询我如何实现。

第一反应是,这个需求本身是不成立的,根据以往的了解,MAC地址应该是过不了路由器的才对。
以往做开发,都是用engineer的思维:先动手做,遇到问题再解决问题。但这个需求,应当用scientist的思维去思考:首先确定能不能做,然后才是怎么做。

翻查了一些资料,想来证实"为什么WEB服务器,可以获取到客户端的IP地址,但获取不到MAC地址",看着看着才发现,这是个挺大的命题,够写一篇BLOG了。

PS:由于个人对这块内容了解的不够彻底,本文很可能会有谬误,请读者先不要太当真,另外希望平台组的同事给予指证。

先说结论

我所认为的结论应该是这样的:

  1. 获取远程主机的IP地址是可行的(先不讨论使用代理的情况)
  2. 本地网络下,当我们已知一个IPv4地址后,可以通过ARP请求,获取对应的MAC地址。换句话说,MAC地址,只在本地网络下才有意义。
  3. 但我们无法透过路由器,获取其它网络下的IPv4节点的MAC地址。

下面一步步解释一下。

HTTP

先从HTTP说起。
HTTP是一个应用层的协议,它建立在TCP协议之上。
HTTP请求就是用来发送一段文本。关于这段文本如何组织,第一行写什么,第二行写什么,哪里加一个空行,就是HTTP协议所要规范的内容。
举个直接的例子,下面是一个简单的HTTP GET请求,有兴趣可以用telnet模拟一下。

GET http://www.fiddler2.com/UpdateCheck.aspx?isBeta=False HTTP/1.1
User-Agent: Fiddler/4.6.3.50306 (.NET 4.0; WinNT 5.1.2600 SP3; zh-CN; 2xx86; Auto Update; Full Instance; Extensions: Geoedge, AutoSaveExt, HostsFile, SAZClipboardFactory, EventLog, SimpleFilter, Timeline, APITesting)
Pragma: no-cache
Host: www.fiddler2.com
Accept-Language: zh-CN
Referer: http://fiddler2.com/client/4.6.3.50306
Accept-Encoding: gzip, deflate
Connection: close

我们可以看到,HTTP的这段请求中,完全找不到客户端的MAC地址,甚至连IP地址都没有描述。
那IP地址是从哪里取到的呢?接下来我们再深入一点,看下一个内容:Socket

Socket

HTTP的客户端和服务端,是通过Socket进行连接的。

Socket是什么呢?Socket是对OSI模型第4层-传输层中的TCP/IP协议的封装。Socket本身并不是协议,而是一个调用接口(API)。Socket和TCP/IP协议没有必然的联系。但通过Socket,我们才能使用TCP/IP协议。应用层不必了解TCP/IP协议细节,直接通过对Socket接口函数的调用完成数据在IP网络的传输。

Socket包含了网络通信必须的五种信息:连接使用的协议,本地主机的IP地址,本地进程的协议端口,远地主机的IP地址,远地进程的协议端口

所以,因为有了Socket,客户端和服务端完全不需要了解底层细节,直接通过调用Socket来实现就可以了。

这也就是为什么服务器端可以获取到客户端的IP地址的原因,因为Socket中包含了远地主机的IP地址。(当然,通过代理服务器进行访问的除外,这种要依靠HTTP协议的X-Forwarded-For头来确认IP,不在本次的讨论范围中)

那为什么无法获取到客户端的MAC地址呢?很简单,同理,因为Socket中无法取到MAC地址。。。

如果继续发问,为什么Socket中都既然都包含IP地址了,为什么偏偏不包含MAC地址信息呢?看来我们还要更深入一点,看一下OSI模型吧。

OSI七层模型

首先祭出这张经典的OSI七层模型图,计算机网络的基石,请先盯着看一会儿,认真复习一下


这里还有一张OSI七层模型与TCP/IP四层模型的对照图


为了方便理解,再放上一张更直观的,每一层对应的数据型式和主要协议的示意图


通过上图大体可以知道:

  • MAC地址是记录在第2层-数据链路层的
  • IP地址是记录在第3层-网络层的
  • 端口号(TCP/UDP)是位于于第4层-传输层的
  • HTTP请求报文是记录在第7层-应用层的

当打开一个URL时,究竟发生了什么

下面举个栗子,当我们在浏览器中打开一个链接后,看看OSI各层倒底发生了什么:
这里撇开DNS解析之类东西,只说一下HTTP报文的发送

1、发送端

首先来看一下发送端(浏览器所在的主机)。参照第一张OSI模型图,按照从上向下的顺序来看。应用层数据其实只有那么几行文本,然后往下,每过一层,都要被加上首部/尾部。这个过程就像是一层一层的穿衣服

HTTP请求文本:



最后到了数据链路层之后,数据就变成了这个肥肥的样子,最后转换成0和1的电信号发出:



下面看看,现实中,每一层都做了些什么(现实中的分层和OSI模型还是有区别的):

  • 第7,6,5层,也就是OSI中的应用层,表示层,会话层(也是TCP/IP分层中的应用层),它创建了一个HTTP请求(例如 GET / HTTP/1.1),并交给下一层。一个普通的HTTP GET请求就是几行纯文本。
    处理这三层,是浏览器WEB服务器所要做的工作,浏览器发出请求,WEB服务器做出响应。

  • 第4,3层,也就是传输层/网络层。TCP/IP栈将上层的数据分成包(packets),并将它送往下一层-数据链路层。
    IP地址、端口号记录在这两层中
    处理这两层,是操作系统要做的工作,操作系统将这两层封装为了Socket,方便调用。

  • 第2层,数据链路层,将包(package)封装成帧(frame),并将它送到下一层物理层。
    MAC地址记录在这一层中
    这一层的工作,交由网卡来处理。

  • 第1层,物理层,使用电信号来传送0和1。
    最后这一层就是传输介质的工作了,例如双绞线、光纤、同轴电缆。

2、数据流转

数据发出去后,再看一下数据在网络上的流转。
数据一般要经过交换机、路由器等网络设备,层层转发,这些设备所做的事情就像是: 脱掉一件或几件衣服,做一些修修补补,然后再重新穿回去

  • 这里先以L2交换机为例看一下,因为L2交换机会认别到帧这一层,记录/学习MAC地址,并将帧发送到目的地。

通过上面这张图,我们就可以理解,MAC地址在本地网络下的重要作用了。也理解了,本地网络下,是可以查出每个节点的MAC地址的。

  • 下面,再来看一下路由器。当一个LAN希望连接到另一个LAN时,就必须使用路由器设备了。当然,可以通过构建超大型的LAN,来避免使用路由器,但这时,交换机就需要管理大量的MAC地址,同时进行大量的广播通信,设备的负担就会相当大。路由器会进行路由选择,让数据达到下一跳。

经过路由器后,为了能到达下一跳,数据链路层中的MAC地址就被篡改了,下面这张图很能说明问题:


3、接收端

最后看一下接收端(WEB服务器所在的主机)。参照第一张OSI模型图,按照从下至上的顺序来看,它要做的事情是: 将衣服一件一件全部脱掉 ,最后WEB服务器就取到了最初的应用层数据。

4、结论

所以,当一个以太网帧到达目的主机后,其中的MAC地址早已经不是原来客户端的MAC了,操作系统的Socket自然也无法获取原始的MAC地址了。

可不可以通过其它方式获取MAC地址

上面已经证明了,WEB服务端,是无法获取客户端的MAC地址的。
那么,能不能通过一些trick来绕道实现呢?
想了想,大概可以有如下的思路:

  1. 通过JavaScrip获取客户端的某块网卡的MAC地址,最好还要同时获取路由表,挑选出走默认路由的那块网卡。
  2. 将MAC地址,偷偷写入应用层的HTTP协议的Header中(类似Content-Type和User-Agent)
  3. 服务端直接读Header,就可以取到Mac地址了

那么这个思路可不可行呢?

  • 如果客户端是浏览器的话,首先第一步就会被打脸,我想也没有哪个浏览器会允许这种不安全的操作的。但如果硬要通过IE下的ActiveX来取的话,貌似也不是不可以。。。
  • 但如果客户端是APP的话,通过WebView+JS Bridge方式调用私有的API,应该也是可行的。。。

记录MAC地址的意义

最后的最后,不禁思考,获取MAC的意义在哪里呢?
如果单纯是为了取证和审计,我想意义是不大的,甚至不如直接记录IP地址。
因为:

  • 对于普通的正常用户而言,通过IP地址,是可以直接定位操作人的,即使IP是动态的。
  • 对于初级以上Hacker来说,伪造MAC地址和伪造IP地址一样简单,甚至更简单。

所以,一般的安全管控要求下,还是只记录IP吧。



作者:bluexiii
链接:http://www.jianshu.com/p/61b1506e4c0f
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
展开阅读全文

没有更多推荐了,返回首页