一个很有意思的人
从2022年开始，野草云的网络、官网一直被攻击，至今未停止，还有加重的趋势。
香港机房产品网络上我们一开始完全依赖网络上游供应商的防御方案，但并不顺利。总结一下遇到了下面一些情况：
1、遇到攻击就全切到美国VOX防护，自动回切时间上不容商量，完全根据规则进行。攻击者只需要1台发包机，对/24发起3个IP或以上的UDP攻击（这非常简单），就可以被判断为扫段/24进入VOX防护路由8-24小时，恢复后再发起一次攻击又可以让我们网络进入VOX。他们无法根据攻击是否停止来进行回切，只能按时、或人工回切；这样攻击成本非常低，都不需要持续发送攻击流量。
2、防护网络质量差，例如全切到美国VOX防护、或美国cogent清洗，全球延迟基本在200ms左右。我们的目标、主要客户是国内用户，别说国内延迟问题了，海外都差的不行，只能说网络“活着”。
3、防护方式太过“传统”，什么是“传统”呢？“传统”就是无差异路由全切VOX，不做近源压制清洗。例如攻击流量都来自欧洲，那么可以仅欧洲方向切到VOX或其他防护路由清洗，他们没有这么做，经典”一刀切“式的解决方案造成所有区域的网络都很差。
针对以上遇到的问题我们之前的网络上游供应商并不是完全没有解决方案，而是没有经济的解决方案。他们也提供本港清洗，即对内地、亚洲优化过的防护方案，计费是根据/24数量。每个/24优惠后费用仍然达小几千每月，且是关照价格、仅限制少量重要客户网段。
实际上虽然遇到了不少问题，但在以前他们的定价并没有什么问题，因为是重成本打造的清洗系统。比如防护用的网络、防火墙都是需要巨资的。亚洲NTT每1Gbps约600usd，之前网络上游供应商一般会接入100Gbps左右，当然大量肯定会有一些折扣；金盾、绿盟集群防火墙部署100-200Gbps防护也需要很多钱的，虽然现在卷便宜了。
在当时VOX、CDN77、CF等一众海外防护对TCP攻击防护能力有限，漏30%左右是常态，即使现在CDN77的TCP防护能力也弱；所以即使拉了VOX、CDN77也需要配合金盾、绿盟这类国产防火墙来应对漏进来的TCP攻击流量。居高不下的防护成本和相对可以忽略的攻击成本让人苦不堪言，小一点的公司只能东躲西藏。很多同行都不想干了，特别是靠价格吸引客户的同行，我其实也不想做香港了，想来年做美国资源了，香港防护成本太高、防护后的质量也差。
这个情况自2023年初开始好转，VOX更新了防火墙可以扛住TCP小包攻击了，海外Wanguard软件防火墙方案也实现了对TCP小包攻击的过滤，可以平替金盾、绿盟这些重成本的硬防火墙了，Wanguard授权一年才一千刀你可以自己配个100Gbps的网卡 :D 所以很多同行包括我都活过来了。
题外话一不小心就说多了……
总之遇到了上面那些情况，结合自建清洗方案的成本开始剧烈下降，2023年中下旬我们就开始计划自己搞防护了，加上有位Cisco CCIE/ Juniper CIE 双证的老师傅加入让我更有信心自己做防护了。
整个2023年至今野草云在宣传上都非常低调，即没有做宣传、广告。我想低调一些攻击也许会轻一些？但并没有，攻击方根据我们的防护变化也在实时进行变化，比如我们屏蔽UDP流量他就打TCP流量，我们把海外流量都传输给VOX进行清洗只保持国内流量的直连他就从国内发起TCP攻击。
今年初，攻击目标还瞄准了野草云官网。这个也很有趣，我们起初用的AWS CloudFront作为前置，没留意被CC攻击刷了10亿左右总请求，流量加请求验证几千刀费用，当然，我没付这个账单跑路了。然后我被迫改成CloudFlare，虽然攻击量还是很大，持续了很长时间，但对访问没影响。因为CloudFlare就算是优选速度也比较慢，我就买了阿里云香港反代源，把国内方向改成阿里云香港，海外方向仍然CloudFlare。
没多久攻击者发现了这个事情，他开始攻击阿里云香港的IP，我无奈又切换回CloudFlare。这样来回几次折腾，我也受不了。我想了个办法，弄了个监测点，如果境内无法访问就自动删除阿里云香港的解析，改回CloudFlare，阿里云IP恢复再自动回切。开始攻击方打完就跑，后来发现不对劲——阿里云香港IP挂了切CloudFlare速度有点快、半夜都有人。然后他就按着阿里云IP打，恢复就打。阿里云香港IP就是脆皮，一打就死，黑洞时间一次比一次长烂的不行，加上野草云自己的清洗系统也慢慢完善了，就换成野草云自己的IP来反代官网源了，他打的费劲了、影响小了才没继续攻击了，但偶尔还是会再来问候一下，就跟朋友一样。
为什么野草云自己卖服务器的要买别人服务器？其实很简单，大多数都不会用自己的服务器做业务 :D 因为万一有什么意外情况能保持官网在线，和客户有个联系的渠道。
还有很多，比如我为什么突然写这个文章呢？因为今天又遇到个事儿，让我想记录一下。
早上我处理值班转给我的工单，说客户请求不到短信。我看了看没什么问题，去看了下submail是不是有维护、还是触发了什么风控，原来是余额为0。我刚充了2万条，给我刷了完了。我查WEB日志锁定了IP地址和不断发起请求的用户，然后CloudFlare开启对IP地址所在国家的WAF规则临时解决了。检查代码发现了一个小错误，1分钟冷却时间是根据用户ID、手机号码2个条件限制的，这样攻击方跳过前端JQ限制，然后不断变化手机号码就可以向后端不停发送请求。
以前遇到这类事情还挺愤怒的，但逐渐的就以平常心看待了。无能怒吼没有意义，放弃抵抗投降更是没有意义。现在我甚至已经把攻击方当朋友了，也许现实中我与他也是相识的，他比我们绝大多数的客户都更了解我们的产品好在什么地方、差在什么地方、哪里有薄弱点，当出现问题总是会在第一时间来”通知你“，你很难相信有人可以坚持不懈持续2年观察你的网络情况并对薄弱的地方进行打击，但我遇到了这样的一个有意思的人，或者说朋友。