wireshark抓包初体验

野性酷女 2024-04-18 23:14 43阅读 0赞

### 文章目录 ###

*   *  一. 使用wireshark对百度进行抓包
     *  二. 对http报文的分析
     *  三. 理解响应失败的原因
     *  四. tcp三次握手

## 一. 使用wireshark对百度进行抓包 ##

进行抓包时, **需要得到ip**(不知道怎么用域名). 我们可以通过`nslookup baidu.com`得到百度的ip, 然而, 在浏览器里访问baidu, ip不是这个命令得到的其中之一, 那么我在浏览器访问`baidu.com`后怎么在wireshark里找?

**我的解决方法是, 在浏览器里不直接输入baidu.com进行查找, 而是输入刚刚查找到的ip, 访问的结果就是baidu.com, 但用这种方法我们可以在wireshark中过滤这个ip.** 如图所示  
![在这里插入图片描述][201909131829002.png]

![在这里插入图片描述][20190913182528260.png]

比如在我这里搜索到的百度的ip是`39.156.69.79`和`220.181.38.148`, 那么我就在浏览器访问`39.156.69.79/s?word=python`, 就在wireshark中过滤这个ip, 得到访问结果.

注意: 在wireshark中使用过滤规则如: **`ip.host == 39.156.69.79`** 限制抓取这个ip的包

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70]  
**还有另一种找ip的方式, 那就是在浏览器检查里找到的baidu的ip.** 但是经过测试这样找到的ip的抓包抓到的包有很多很多, 比上面那种多多了, 从包的协议来看, 第一种应该都是http, 而第二种应该是https. 我认为初学者可以先用前一种方法抓百度的包, 从简单的开始分析. (关于这个后面有个彩蛋)![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 1]

## 二. 对http报文的分析 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 2][]  
查看抓取的包, 有两个http协议, 其中第一个是我的ip发起的请求, 第二个是百度对我的回应.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 3]  
点进去, 查看详细内容, 可以看到这段http请求报文. 虽然和<<自顶向下>>书上的不完全一样, 但包含的信息是差不多的.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 4]  
这个是响应报文, 他给了我们一个302状态码, [维基百科的解释][Link 1]是这样的:

> 302 Found，原始描述短语为 Moved Temporarily ，是HTTP协议中的一个状态码(Status Code)。可以简单的理解为该资源原本确实存在，但已经被临时改变了位置；换而言之，就是请求的资源暂时驻留在不同的URI下\[1\]，故而除非特别指定了缓存头部指示，该状态码不可缓存。  
>   
> 对于服务器，通常会给浏览器发送HTTP Location头部来重定向到新的新位置。

这说明没有成功响应…

## 三. 理解响应失败的原因 ##

**所以我好像明白了什么, 因为使用第一个方法找到的ip访问时, 它似乎经过了一个重定向, chrome浏览器的锁那里先是显示不安全, 然后进入了`baidu.com`. 所以有理由认为使用`nslookup`命令找到的ip进入的服务器使用的是http, 并不安全, 于是自动重定向到了https.**

**而这也是我们最开始发现的, 第一种方法得到的包很少的原因了**

于是我去验证一下, 在没有直接通过https的百度ip访问百度的情况下, 过滤该ip的包, 看是否有很多包. 事实确实是这样, http自动重定向到了https. 有很多的包.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 5]  
所以得出一个结论:  
**上面我介绍的第一种方法得到网站ip然后过滤抓包的方法是不可取的, 建议还是用在浏览器上用检查去获取网站的ip.**

如图所示为加上`ssl`条件过滤, 协议都是`TLSv1.2`了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 6]

## 四. tcp三次握手 ##

然而我们的第一种方法完全没有价值吗? 并不, 前面说了, 它抓的包很简单, 而且是http协议. 书上介绍相关内容时, 是先从http介绍的, 因此我们可以用第一种在现在渐渐淘汰的http理解课本内容.

我想说的是http请求时的tcp三次握手.

> 第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN\_SEND状态，等待服务器确认；
> 
> 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN\_RECV状态；
> 
> 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
> 
> 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主  
> 动关闭连接之前，TCP  
> 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客  
> 户端交互，最终确定断开）

如图所示, 三次握手建立起了tcp连接  
![在这里插入图片描述][20190913191112962.png]  
出现了 `SYN, ACK` 这几个专业术语  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 7]  
因此我们可以直观地感受到tcp建立连接的过程

--------------------

这一次不是非常顺利但收获颇多的抓包学习，在抓包的过程中遇到好些问题，然后在解决问题的过程中发现自己的漏洞，和一些新的猜测并验证。

参考： https://www.cnblogs.com/tiwlin/archive/2011/12/25/2301305.html

[201909131829002.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1b949b92c04a42ee8f4e3fc8c082a03a.png
[20190913182528260.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5b79293417c64090b034ec8c82df7cf9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/deb0e60b8fa946dd81c877fed0353676.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a11eef6776e243ff821b407278114566.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/3c4d6c809cdc4f32b8db21401e4a0bef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c751ebc3382a446d9a407d58cc8ec205.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/39292d9f65c841c2a4fcbafeff945e58.png
[Link 1]: https://zh.wikipedia.org/wiki/HTTP_302
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/abe1a5c537484379a2896ea2c6063c49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/27aba57dc6d94f96a693b3ea6d875c4e.png
[20190913191112962.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/71ce7e79908244ceb278df2fd3c56e9a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc_size_16_color_FFFFFF_t_70 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/bb53de44a68f4a57b5cd1e337e769713.png