背景
手头有一台祖传搬瓦工服务器,一直跑着一些众所周知的服务,家里主路由是openwrt,家里的设备通过openwrt的插件和搬瓦工建立着密切的链接:)
这套组合运转了N年一直平安无事,直到前些天邮箱收到这么一封邮件。

赶紧登录到搬瓦工panel上面瞅一眼,果不其然,机器已经被suspend掉了。原因是Network Abuse: Mass Mailing.

严格点说,这类邮件六月份就收到一次了,当时折腾了几次没有啥结果,于是暂时忽略。这次又出现了,不得不重视起来,认真排查下。
这里提一下搬瓦工的abuse政策,每次违反tos,都会记100分abuse point,记满10次,当年会直接停止服务。(据说如果真的记满了,可以交50刀恢复服务)
思路
在我们这个场景下, 服务器发了垃圾邮件,无外乎一下几种可能。
- 服务器被黑
- ss服务暴露
- 内网设备感染蠕虫
- 其他
网上搜索了下,发现案例不多,排查经过比较详细的是这位老哥(链接),参考了下,我觉得1和2的可能性不大。
因为问题是垃圾邮件,所以我们排查的关键词是“mail”和“993”端口。
排查
思路上面已经整理好了,挨个排查就好。
检查服务器是否被入侵
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的怀疑
出处见上文
有上文老哥的验证,基本已经排除这个原因了。
不过还是快速过下我这边的情况,我的搬瓦工只跑了ss服务和一个SimpleHTTPServer,随机端口,强密码,强iptables规则,虽然我没啥渗透背景,不过被黑的概率实在太低了。
登上去看了看,没啥蛛丝马迹,pass。
检查ssserver服务
查看ssserver日志
# 打印ssserver日志
nohup ssserver -c config.json >> ss.log 2>&1 &
# grep日志
tail -f ss.log | grep "mail\|:993"
开着窗口守株待兔,过一会(也可能是一下午),就可以看到请求日志了。

OK,现在我们可以证明,请求确实是从shadowsocks这边发出去的。
至于ss服务暴露的可能,我设置了iptables,只接受来自openwrt的请求,所以这个猜测直接pass。
检查内网
现在基本可以确定,问题发生在家里这一坨设备上。
在openwrt上记录了内网dns请求,iptables报文和shadowcks链接。操作方法见配置openwrt的网络请求日志。
打好日志,挂了一晚上,第二天起床拉下日志,果然发现993端口记录,下面开始分析。

一番搜索下来,结果如下。
1.dns日志没有出现问题域名
2.shadowsocks日志有问题域名!
3.很遗憾配置时候手滑了,iptables日志没打上。
这里思考下,为啥会出现12两条的结果。
通过openwrt连接shadowsocks有两种形式,一种是透明代理,一种是socks5代理。前者客户端是无感的,访问流程是dns->openwrt根据目标ip分流->IP报文;后者类似SwitchyOmega,需要在客户端中显式配置socks5代理,所有请求都通过shadowsocks转发。
既然dns请求中没有留下日志,我们可以确定,请求来自socks5代理!
排查koolss
在openwrt上,我用的ss插件是koolss,虽说这是个闭源插件,一番研究下来,我还是找到了它的启动脚本。
启动ss-local的逻辑在/koolshare/ss/ssstart.sh的570行左右,详情见配置openwrt的网络请求日志。这里我直接贴一段代码。
start_sslocal(){
if [ "$ss_basic_type" == "1" ];then
echo_date ......ssr-local.........socks5.........23456
ssr-local $SPECIAL_ARG -l 23456 -c $CONFIG_FILE -u -f /var/run/sslocal1.pid >/dev/null 2>&1
elif [ "$ss_basic_type" == "0" ];then
echo_date ......ss-local.........socks5.........23456
if [ "$ss_basic_ss_obfs" == "0" ];then
ss-local $SPECIAL_ARG -l 23456 -c $CONFIG_FILE -u -f /var/run/sslocal1.pid
else
ss-local $SPECIAL_ARG -l 23456 -c $CONFIG_FILE -u $ARG_OBFS -f /var/run/sslocal1.pid
fi
fi
}
我们可以看到,在line8和line10,koolss启动了一个hardcode的23456端口socks5代理!
定位问题
到底是哪个客户端连接了koolss的socks5代理呢?因为前面的配置问题iptables没有留下日志,排查到这我有点挠头。
灵机一动,看下socks5连接情况。
netstat -nat | grep 23456

破案了!
等等,这里的远程ip为啥都是外网?
心里咯噔一下,忽然想起,前段时间某次调试问题,把openwrt的防火墙全改成accept了。当时想着公网内网中间隔着一层nat,应该压力不大,万万没想到,还有这么个端口在,这个端口还是被脚本给扫出来了,给人家当了不知多长时间免费代理。
结论&解决方法
写到这,相信这个case的原因大家都清楚了。
总结一下,就是koolss开放了一个固定端口且不加密的socks5代理,openwrt上配置的防火墙规则不够严谨,导致被人扫到并滥用了代理。
解决方法也很简单,openwrt中把公网到内网的防火墙规则改成reject就好。

最后说句题外话,虽然我对koolshare的好感度实在不高,我还是倾向于相信这是个无心之失,因为koolss也是魔改自大众版本的shadowcks-openwrt,这个socks5端口未必是koolshare的原创。况且按照大部分人的配置,wan->lan的请求,应该是默认reject掉的。
update:openwrt显式配置的端口转发和upnp之类的服务,不会受这个配置的影响,不放心的话可以自己验证下。
最后的最后,再次提醒大家,信息安全无小事,自己的服务一定做好监控做好权限管理!
——此处是内容的分割线——
除非注明,否则均为广陌原创文章,转载必须以链接形式标明本文链接
本文链接:https://www.utopiafar.com/2022/08/11/bandwagon-mass-mailing-problem/
码字不易,如果觉得内容有帮助,欢迎留言or点赞!
《“解决搬瓦工垃圾邮件问题”》 有 6 条评论
你好,我是那片博的作者,非常感激您找到了最终解决方案。可是有个疑问,wan过来的入站与转发都改为拒绝后,不会影响到一些正常转发吗?
不会的,这个端口转发和防火墙规则都是iptables实现,手动配置的端口转发优先级比防火墙高。
【亲测可用
嗯哼,已经按照这个方法设置了,并且把方法更新到我那篇里面去了,做了出处引用,谢谢!
感谢,从gabrielgon过来的。我用的是lean的openwrt,因为固件的编译者关闭了ipv6,导致端口转发有点问题。为了在ipv6的地址用webdav,因此在WAN口打开了接收规则,结果shadowsocksplus的1080端口以及服务器节点的本地端口会直接暴露在公网,不知道被谁扫到了,一堆QQ的垃圾邮件。
在2022年还能看到这种技术性文章简直泪流满面,解决了我的大问题
感谢分享,愿互联网精神永在
感谢支持!能帮到人很开心:)
确实帮了很大忙,谢谢