搬瓦工Mass Mailing问题解决

被搬瓦工的VPS MASS MAILING问题困扰了好久，google、百度、github全网搜索，发现零星几个案例，无一例外都是搬瓦工的VPS的，可是所有案例均无解

症状表现

1、只要openwrt，通过SSRP+连接到VPS，短则3～5分钟，快则2天，VPS那边必定暂定服务，原因是Mass Mailing，瓦工有1200积分，一次问题扣除100积分，也就是一台VPS只有12次机会解决这个问题

2、不用openwrt连接VPS，服务一切正常

3、通过openwrt连接非搬瓦工VPS，服务一切正常，发包也正常

4、通过openwrt连接搬瓦工VPS，通过tcpdump查看发包，会发现从openwrt发送大量的smtp/imap请求到VPS，主要端口是25和993

排查过程

1、瓦工的客服不会对这个问题协助你排查，发工单无用，50刀可以恢复积分

2、为了解决这问题，又买了一台搬瓦工的VPS，网段与原来的不一样，原来的网段是173，新买的网段是23。后续排查均在用23这台全新的VPS做的测试。

3、用甲骨文服务器做了一台日志服务器，实时记录tcpdump内容与路径

4、23服务器，不通过openwrt连接，一切正常（包括手机端小火箭、PC端V2RAYNG等）

5、23服务器，只要通过openwrt的各种客户端连接V2服务，立刻出现大量的邮件请求（通过25和993）

6、通过openwrt连接其他非搬瓦工VPS（hostdare、甲骨文等），诡异的事情就出现了：不会发任何邮件请求，干干净净

7、想着难道是VPS问题？不应该啊，首先是强密码（随机英文大小写、数字、符号混合20位），而且就算被VPS被破，也不至于几分钟就锁定我新买的VPS，然后给破了？如果有这毛病，搬瓦工早就炸了吧？

8、虽然有着“7”的疑惑，可是仍然还是重置了主机，并且全新安装vps自带的ubuntu 20.04.3，仍然20位强密码，并且环境内只安装fly的v2官方源。并通过KVM后台做镜像（23VPS_ORG）并下载

9、立刻通过openwrt连接23服务器的V2服务，好了1天半，收到邮件 Mass Mailing

10、想着1天半，也许某位隐藏大佬盯着我在弄呢，那我对比镜像总行了吧，把VPS端恢复，并立刻做镜像（23VPS_BLK），并下载，准备与（23VPS_ORG）做比较

11、发现23VPS_BLK与23VPS_ORG的MD5/SHA256一毛一样。。。不甘心，开始打开包比对，仍然发现一毛一样。。。啥手段能做到这么不漏痕迹的黑掉一台VPS？逐放弃对VPS的怀疑

12、那是客户端的问题？于是开始了1周的终端测试，发现不管是移动端还是PC端还是MAC端，用任何客户端都一切安好，毫无问题

13、福尔摩斯·鲁迅说过，排除掉一切不可能，那你眼前最相信的事情就是一直在骗你。遵循老一辈哲学家的指引，怀疑对象转到了OPENWRT本身

14、OPENWRT用的是eSir的GDQ8.1（后来换到GDQ9.1，一毛一样）。装的环境是一台minisforum的U820，为了干净的环境，这一台主机我就放了一个OPENWRT GDQ8.1(9.1）系统

15、把U820格式化，全部清空，并且断电、清除内存信息，确保这台机器是绝对的纯洁干净

16、通过U盘安装OPENWRT eSir GDQ9.1（是的，正好这时候9.1出来了）

17、在纯净的OPENWRT系统下，配置好能PPPOE之后，不动任何其他配置，直接通过SSRP+挂到搬瓦工的23VPS

18、好了一晚上（大概5～6小时），收到 MASS MAILING 警告，并暂停服务，于是对OPENWRT怀疑加重

19、用甲骨文的VPS做了一个日志服务器，实时记录tcpdump的信息，以免23VPS被暂停后，所有日志丢失无法查看排查

20、通过OPENWRT连接到23VPS后，立刻出现大量的MASS MAILL请求，主要通过25和993端口，初步锁定这个MASS MAILL蠕虫是通过SMTP和IMAP进行发送，怪不得之前在老的173VPS关闭25还会收到警告

21、为了验证针对性，再次通过OPENWRT的SSRP+连接到hostdare、甲骨文的VPS，抓包信息仍然干干净净，不发送任何异常请求。合着这蠕虫就逮着搬瓦工薅啊～

解决方案

2022/8/12更新@广陌 的解决方案，大致就是“koolss启动了一个hardcode的23456端口socks5代理” 导致，具体原因可跳转过去观看。

不过这个方法我也刚刚用，还在测试中

总结一下，就是koolss开放了一个固定端口且不加密的socks5代理，openwrt上配置的防火墙规则不够严谨，导致被人扫到并滥用了代理。

解决方法也很简单，openwrt中把公网到内网的防火墙规则改成reject就好。

最后说句题外话，虽然我对koolshare的好感度实在不高，我还是倾向于相信这是个无心之失，因为koolss也是魔改自大众版本的shadowcks-openwrt，这个socks5端口未必是koolshare的原创。况且按照大部分人的配置，wan->lan的请求，应该是默认reject掉的。

以下为老的解决方案

1、发现Passwall服务可以禁用转发端口，于是在tcp和udp禁用了25,465,587,143,993,110,995

2、运行了几分钟没啥问题，抓包也没发送了，可是不放心

3、于是在VPS直接禁用这些端口，永绝后患

iptables -A OUTPUT -p TCP --dport 25 -j DROP
iptables -A OUTPUT -p TCP --dport 110 -j DROP
iptables -A OUTPUT -p TCP --dport 465 -j DROP
iptables -A OUTPUT -p TCP --dport 587 -j DROP
iptables -A OUTPUT -p TCP --dport 993 -j DROP
iptables -A OUTPUT -p TCP --dport 995 -j DROP
iptables -A INPUT -p TCP --dport 25 -j DROP
iptables -A INPUT -p TCP --dport 110 -j DROP
iptables -A INPUT -p TCP --dport 465 -j DROP
iptables -A INPUT -p TCP --dport 587 -j DROP
iptables -A INPUT -p TCP --dport 993 -j DROP
iptables -A INPUT -p TCP --dport 995 -j DROP
 iptables -L -n

4、继续抓包，禁用之后，发现OPENWRT特么不发包了，估计是这蠕虫会先判断服务器端/客户端的这些端口是否开放，开放就发，不开放就不发

这个问题至此，花费了2000多块买主机，历时2个月，总算是解决了，可是此做法仍然是治标不治本，而且这样做的坏处是，你的这台VPS的邮件功能（SMTP和IMAP）均无法使用，恢复如下：

iptables -F OUTPUT -p TCP --dport 25 -j DROP
iptables -F OUTPUT -p TCP --dport 110 -j DROP
iptables -F OUTPUT -p TCP --dport 465 -j DROP
iptables -F OUTPUT -p TCP --dport 587 -j DROP
iptables -F OUTPUT -p TCP --dport 993 -j DROP
iptables -F OUTPUT -p TCP --dport 995 -j DROP
iptables -F INPUT -p TCP --dport 25 -j DROP
iptables -F INPUT -p TCP --dport 110 -j DROP
iptables -F INPUT -p TCP --dport 465 -j DROP
iptables -F INPUT -p TCP --dport 587 -j DROP
iptables -F INPUT -p TCP --dport 993 -j DROP
iptables -F INPUT -p TCP --dport 995 -j DROP
iptables -L -n

然后，如果你的系统是Ubuntu20 （如我的是20.04.3 LTS），因为UWF的原因，要进行一些特殊处理：

第一步：

iptables -A OUTPUT -p TCP --dport 25 -j DROP
iptables -A OUTPUT -p TCP --dport 110 -j DROP
iptables -A OUTPUT -p TCP --dport 465 -j DROP
iptables -A OUTPUT -p TCP --dport 587 -j DROP
iptables -A OUTPUT -p TCP --dport 993 -j DROP
iptables -A OUTPUT -p TCP --dport 995 -j DROP
iptables -A INPUT -p TCP --dport 25 -j DROP
iptables -A INPUT -p TCP --dport 110 -j DROP
iptables -A INPUT -p TCP --dport 465 -j DROP
iptables -A INPUT -p TCP --dport 587 -j DROP
iptables -A INPUT -p TCP --dport 993 -j DROP
iptables -A INPUT -p TCP --dport 995 -j DROP
iptables -L -n

 测试

telnet smtp.163.com 25
telnet imap.exmail.qq.com  993
telnet imap.exmail.qq.com  995

 第二步

iptables-save > /etc/iptables.up.rules
echo -e '#!/bin/bash\n/sbin/iptables-restore < /etc/iptables.up.rules' > /etc/network/if-pre-up.d/iptables
chmod +x /etc/network/if-pre-up.d/iptables
cat /etc/network/if-pre-up.d/iptables

 第三步

reboot

然后

telnet smtp.163.com 25

 测试不通则成功

这蠕虫本身肯定还存在于OPENWRT或者SSRP+服务中，要是OPENWRT有杀毒软件能扫就好了。。。杀不死就和谐共存吧。希望有大佬能告诉我更优甚至能治本的解决方案