如何找到制造网络流量的源头 - 运维

今天收到告警，带宽利用率超过90%，查看流量监控发现流量几乎打满，需要找到流量打满的原因以及是谁制造了这些流量。

1. 先使用 nethogs 工具找出使用了带宽的进程，它可以显示流量两端IP和端口号，以及进程ID，这样很容易知道对方访问了什么服务导致的流量异常。

sudo nethogs

通过命令输出结果得到以下IP和端口流量最高。
10.8.1.3:3129-10.0.7.248:40142

2. 登录 10.0.7.248 查找使用 40142端口的服务或者进程。

sudo apt-get install conntrack
sudo conntrack -L | grep 40142
得到以下结果：
z@s750:~$ sudo conntrack -L | grep 40142
tcp 6 84 SYN_SENT src=172.17.0.2 dst=10.8.1.3 sport=40142 dport=3129 [UNREPLIED] src=10.8.1.3 dst=10.0.7.248 sport=3129 dport=40142 mark=0 use=1
conntrack v1.4.5 (conntrack-tools): 13821 flow entries have been shown.
z@s750:~$

3. 有此可见是 172.17.0.2 IP访问的，而172.17.0.2是docker容器的IP。

z@s750:~$ docker inspect openvpn|grep 172.17.0.2
"IPAddress": "172.17.0.2",
"IPAddress": "172.17.0.2",
z@s750:~$

4. 执行容器的bash命令进入容器，安装tcpdump抓包工具，看是哪一个VPN IP 在访问 10.8.1.3:3129 。

bash-5.0# vi /etc/apk/repositories
bash-5.0# cat /etc/apk/repositories
#http://dl-cdn.alpinelinux.org/alpine/v3.12/main
#http://dl-cdn.alpinelinux.org/alpine/v3.12/community
#http://dl-cdn.alpinelinux.org/alpine/edge/testing/

http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/main
http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/community
bash-5.0# apk update
fetch http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
v3.12.12-53-gc96f3238172 [http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/main]
v3.12.12-52-g800c17231ad [http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/community]
OK: 12780 distinct packages available
bash-5.0# apk search | grep tcpdump
tcpdump-doc-4.9.3-r2
tcpdump-4.9.3-r2
bash-5.0# apk add tcpdump
(1/2) Installing libpcap (1.9.1-r2)
(2/2) Installing tcpdump (4.9.3-r2)
Executing busybox-1.31.1-r19.trigger
OK: 17 MiB in 38 packages
bash-5.0#

bash-5.0# cd /etc/openvpn/
bash-5.0# ls
EasyRSA-3.1.6 EasyRSA-3.1.6.tgz ccd crl.pem openvpn.conf ovpn_env.sh pki
bash-5.0# tcpdump -i any host 10.8.1.3 and port 3129 -s 0 -w target_traffic.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
^C425623 packets captured
426228 packets received by filter
0 packets dropped by kernel
bash-5.0#

使用以下命令进行查看数据包和抓包
tcpdump -i any host 10.8.1.3 and port 3129 -nn -vvv
tcpdump -i any host 10.8.1.3 and port 3129 -s 0 -w target_traffic.pcap

5. 经过wireshark 流量分析，发现流量来自 172.16.248.22 这个VPN IP。

6. 通过openvpn status 文件查询172.16.248.22所属的OpenVPN客户端是腾讯云上的一台云服务器 tke-xxx。

7. 登录 tke-xxx 使用 netstat -anop|grep 3129 找到流量来源进程是 haproxy 。

8. 发现HAProxy 配置是如下所示：

frontend main
bind 10.12.32.13:3127
mode tcp
default_backend app

backend app
mode tcp
server app1 10.8.1.7:3127

frontend qcproxy
bind 10.12.32.13:3129
mode tcp
default_backend qcbackend

backend qcbackend
mode tcp
server qcbackend 10.8.1.3:3129

9. 通过公网IP检查端口，发现IP:Port可访问，因此需要在安全组中添加拒绝规则并仅允许指定节点IPv访问。

总结：

1. 根据最终结果看，虽然HAProxy监听的是本地IP地址，但由于云服务器EIP的端口与云服务器内网IP监听端口是一一对应关系，所以公网IP也监听了这些端口，造成被公网扫描并使用。

2. 对于配置变更应该记录清晰，并且分析配置变更可能带来的影响。本次问题是由于tke的一个节点添加了EIP，由于原来节点都是内部使用所以安全组设置较为简单，只对部分端口做了限制，但没有默认设置为阻止，所以开了新的端口后没有及时更改安全组规则，导致内部服务端口暴露到公网。

3. 安全组、防火墙建议默认使用阻止，使用白名单模式而不是黑名单模式。