Tcpdump在数据库中的使用实践

开工大吉,一篇高品质技术干货送给大家

一、概述

tcpdump就是dump the traffic ona network,根据使用者的定义对网络上的数据包进行截获的包分析工具。需要root用户或者有sudo权限的用户才可以执行tcpdump。

二、选项介绍

1、-i any: 监听所有的流量。这样你就知道是不是有流量产生。

2、-n: 不要解决主机名,以IP数字形式显示主机。

3、-nn: 不要解析主机名或端口名字。

4、-v, -vv, -vvv: 详细,更详细,再详细些! 冗余输出得到的包信息。

5、-c: 抓取 x 个包后就停下。

6、-s: 设置显示前多少个字节的包内容(snaplength)。

7、-w: 写入文件,把抓取到的内容存入该文件内。以后还可以用 -r 指定文件,把以前存入的内容再读回来。这是一个相当不错的方法,可以先抓取包,以后再用各种工具分析。

以这种形式抓到的流量是以tcpdump的格式储存的。这种格式在网络分析的工具之间非常通用。这意味着,像 Wireshark, Snort, 等工具也可以读取它。

三、使用实例

(1) 截获所有210.27.48.1 的主机收到的和发出的所有的分组:

# tcpdump host 210.27.48.1

(2) 截获主机210.27.48.1 和主机210.27.48.2或210.27.48.3的通信,使用命令(注意:括号前的反斜杠是必须的):

# tcpdump host 210.27.48.1 and \(210.27.48.2 or 210.27.48.3 \)

(3) 截获主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包,使用命令:

# tcpdump ip host 210.27.48.1 and !210.27.48.2

(4) 截获通信协议为port 22,目标来源为192.168.1.100的数据包:

# tcpdump -nn port 22 and src host 192.168.1.100

四、Tcpdump解决实际问题

案例一

如果应用程序连接数据库,输入了错误的密码,在mysql 5.7的错误日志文件有对应log:

而mysql 5.6的错误日志文件没有类似信息,遇到这种情况,可以用tcpdump找到报错的主机和用户名。

首先在目标数据库主机,开始抓包

# 只抓3769端口的包,每个包最大为1520字节,最多抓40000个数据包,抓到的包写到tcpdump.pcap文件,方便后面做分析

tcpdump -i any tcp and port 3769 -s 1520 -c 40000 -w tcpdump.pcap

输入错误的mysql密码,登录报错后,停止抓包

可以看到一共抓到了82个包,过滤了171个包。

将pcap文件下载到电脑后,可以使用Wireshark进行分析。

Wireshark是一款支持多平台的包抓取分析开源软件,前身是ethereal。

用Wireshark打开pcap包,搜索密码错误报错的关键字"denied",可以找到数据库给应用返回报错的数据包。

找到抓包时间内出现过密码错误的报错,抓包记录中有应用所在主机ip(Destination ip),数据库所在主机ip(Source ip),数据库端口(Source Port),错误时间(Time)。

案例二

有时候,应用端慢sql日志抓到了一条sql语句,但是在数据库的慢sql日志却没有。这种情况怎么定位问题呢?如果简单的说数据库没有问题,是没有说服力的,还得拿真实数据说话。这个时候也可以通过tcpdump来定位问题。

1

在数据库210的主机上开始抓包

tcpdump -i any tcp and port 3769 -s 1520 -c 40000 -w tcpdump.pcap

应用程序抓到了一个慢sql,慢sql执行时间为700ms,执行的sql为:select count(0) from test_table1。此时停止抓包

2

下载tcpdump.pcap包

下载tcpdump.pcap包,用Wireshark打开进行分析

3

跟踪TCP流

搜索关键字test_table1,找一条记录,Time记录的时间跟sql实际执行时间一致。

在找到的记录上点击右键,跟踪TCP流

4

分析TCP流有四条记录

这条记录相关的TCP流有四条记录,下面详细分析一下这四条记录

第一条记录:

这条记录是211的应用机器给数据库发的执行sql,发送时间是2018-02-09 10:55:06 868076,右下角可以大概看到是我们执行的sql语句。

第二条记录:

这条记录是数据库210收到sql后,给应用主机211发的确认ACK,表明已收到sql,发送时间是2018-02-09 10:55:06 868081。右下角是一堆类似乱码的字符。

第二条记录减去第一条记录的时间为0.005ms,即应用发送执行sql到数据库接收到sql,耗时大约5微妙。

接下来看第三条记录:

这条记录是数据库执行完sql,把结果发给应用。发送时间是2018-02-09 10:55:07 547763。第三条记录的时间减去第二条sql的时间,为679.682ms,这是时间是数据库执行sql所需的时间。

第四条记录:

这条记录是应用给数据库返回确认ACK,表明应用已收到数据库发送的查询结果。

发送时间是2018-02-09 10:55:07 547849。第四条记录的时间减去第一条记录的时间,为679.773ms,这个时间是应用发出sql到接收到结果的时间。

应用记录的慢sql执行时间为700ms,跟679.773相差不大,可以判断整过过程中没有丢包重传,也没有其他耗时的操作,真正慢在了数据库端。查看数据库的慢sql日志阈值是1秒,自然是没有抓到慢日志的。

5

总结

以上是tcpdump解决的两个简单案例,tcpdump还可以诊断网络是否有丢包,网络延迟等问题。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180227G0VLY600?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券