解决搬瓦工垃圾邮件问题

Contents

背景

手头有一台祖传搬瓦工服务器，一直跑着一些众所周知的服务，家里主路由是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点赞！

8月 11, 2022

utopiafar

OpenWrt, 踩坑

bandwagon, openwrt, shadowsocks, 踩坑