2025年11月

早晨刚想出门,收到一个告警短信,物联网登录分配服务器正常节点异常。
一猜就是扛不住压力。
压力来自大量物联网设备以及 APP 在登录。
为什么压力大呢?
可能有地方有问题。
紧急处理,打开登录限流服务(Jenkins 任务)。
过了十分钟,恢复差不多。
但是,又出现了问题。
好家伙,开启降级服务,关闭物联网设备自动写上报数据到 redis 集群。
然后,就慢慢恢复正常了。

吃过早饭,骑车去公司。

坐到办公室,继续排查。
这个时候,其他同事已经陆续到了。
查看 redis 集群监控图,注意到一个 keys 指令几十毫秒。
记得之前有一位新来的研发工程师说 keys 会导致锁库,导致 select update 等类似 mysql 的指令无法正常工作。
研发同事去排查keys 指令。
可是这个与我们遇到的问题时间点上无法吻合。keys 指令是整点定时任务,可是问题出现在7:11 分多一点点。

架构师抛出来一张 redis 一个实例 cpu100%的图片。
这个可能是直接导致物联网长连接服务器异常的原因。

开始针对该redis 实例的问题进行排查。
redis 集群从三主三从升级到了八主八从,也消灭了一些大 key。
异常 redis 实例还挂掉了,导致了主从切换。
先把主从节点切换回来。
查看数据,对比不同实例,发现该异常节点 cpu 使用率 3 个月以来持续攀高,就在已经关停实现降级服务的情况下,依旧有将近 60 的使用率,而其他redis 节点大概只有 10%~30%的使用率。
多次比较后,发现了一个 keys 指令,对应的一个 key 大概是热key。
最终导致该节点每秒节点处理时长大概有 500ms 左右,而其他节点大概只有几十 ms。

定位了热key,跟研发同事一说,等他们修复了。

中午好好的吃了一些饭,少吃米,多吃菜。

本来以为下午可以看看书,整理整理文档,谁知一个运维代为服务客户发来一个视频,说是充值失败。
我寻思着,这充值是代码问题,为啥失败呢?且这个客户不知道为啥,只有一个服务器,没有文档,也不知道架构。
早先因为 tomcat 直接暴露了 8080 端口到公网,且是 两三年前部署的服务,被黑客攻击并进行了挖矿。
后来,加入了 waf 以及关闭了 8080 直接对外,更新了 https 证书,已经稳定运行了有半个多月。
看到客户在群里发消息,我只是在思考,没有先回答。

回到工位,开始搜索 pfx pem 等支付通信所用到的证书。
后来搜索到了一个 tengxun 支付的证书,但是没有与程序结合的线索。
干脆直接从日志中找找,搜索关键字 pay 还真找到了一些。
有通信参数,有接口地址。通过域名锁定了 tomcat 程序位置。
日志有 1GB,压缩下载到本地。
使用 ai 进行分割文件,每个 20MB。
通过 ide 工具从尾部向上找,找了几个找到了 pay 相关的具体日志。
通过 ai 分析,发现是 xstream 模块版本不支持反序列化(之前升级了有漏洞版本)。
这下心里大概有数了。

这个时候,用户也把今年充值的记录拿出来了,一个是 6 月份一个是 9 月份。
看来充值频率不是很高。
跟用户解释,可能是之前再做安全修复的时候(比照着阿里云安全中心给的提示),升级了包括 shiro fastjson xstream 在内的模块。
升级后,漏洞是补上了一些,但是由于没有源代码导致兼容性没有充分验证。

替换后,打开 tail 查看 catalina.out日志并过滤 pay。
过了好一会儿,看到终端提示有新数据,发现已经返回正常了。

长舒一口气,这一天。

RDDOS:从被入侵到主动反击,一个运维的安全觉醒

认知上的最大竞争,其实是信息输入量的竞争。你输入的信息越多,你看待问题的视角会更多元,分析问题也会更有深度,也就具备了洞察力。

2025年9月,一个普通的下午,我的服务器被入侵了。

某机构利用了一个带有漏洞的、暴露在公网的Tomcat程序,成功渗透进了我的系统。当我发现时,数据已经被窃取,系统已经被破坏。那种无力感和愤怒,至今记忆犹新。

痛定思痛,我决定做些什么。

我做了两件事:

第一件事,在程序前端部署了WAF(Web应用防火墙),避免服务直接暴露在公网。这是防御的第一步。

第二件事,我想知道:还有谁在盯着我的服务器? 常规的蜜罐系统太专业、太复杂,我需要一个简单的方案——一个对互联网主动暴露的端口,只要有人访问,就说明有问题,因为这个端口根本不是正常的服务端口。

更重要的是,被入侵加上心情低落,我要反击。这就是RDDOS(反向DDoS防护)诞生的原因——不是被动防御,而是主动反击。

今天,让我们通过8个关键问题,深入理解这个从真实痛点中诞生的防护系统。


1. 我要说的是什么概念?

RDDOS(Reverse DDoS),即反向DDoS防护系统。

与传统的被动防御不同,RDDOS采用了一种"以攻为守"的策略。它不仅仅是被动地承受攻击,而是主动地识别攻击者,并实施反向打击。

核心特征包括:

  • 主动监听:监听TCP端口,捕获所有连接尝试
  • 智能识别:通过访问频率、连接模式等特征识别攻击行为
  • 反向反击:向攻击者发送大量数据,消耗其带宽和资源
  • 自动封禁:集成防火墙系统,自动将攻击IP加入黑名单
  • 多层防护:从应用层到网络层的全方位防护体系

这不仅仅是技术层面的创新,更是防护思维的转变:从"被动挨打"到"主动出击"。


2. 这个概念为什么重要?

被入侵后,我意识到传统防护的局限性:

  • 被动响应:只能在攻击发生后才能采取行动
  • 成本高昂:需要购买昂贵的商业安全服务
  • 复杂度高:专业蜜罐系统需要深厚的安全知识
  • 无法反击:只能被动防御,眼睁睁看着攻击者得逞

RDDOS解决了这些痛点:

  1. 简单易用:配置文件化,一键部署,普通开发者也能使用
  2. 主动识别:连接建立的第一时间就能识别并响应
  3. 成本转移:将资源消耗从防御方转移到攻击方
  4. 自动化:自动完成检测、反击、封禁全流程
  5. 反击能力:让攻击者付出代价,不再被动挨打

正如亦仁所说,信息输入量的竞争决定了认知的深度。理解RDDOS,就是理解一种从真实痛点中诞生的、简单而有效的安全防护范式。


3. 这个概念普遍被如何误解?

误解一:RDDOS是攻击工具

错误认知:很多人看到"反向攻击"、"洪水攻击"等字眼,就认为RDDOS是用于攻击他人的工具。

实际情况:RDDOS是纯粹的防御系统,只在自己的服务器上运行,只对主动连接自己服务器的IP进行防护。它不会主动扫描或攻击其他服务器。

误解二:反向攻击是违法的

错误认知:认为向攻击者发送数据包可能涉及法律问题。

实际情况

  • RDDOS只在自己的网络边界内运行
  • 它只是对已建立的TCP连接进行响应
  • 这是合法的自我防护行为,类似于"正当防卫"
  • 关键在于:只防护自己的资产,不主动攻击他人

误解三:会误伤正常用户

错误认知:担心系统会错误地封禁正常用户。

实际情况

  • 系统提供多种策略,包括基于阈值的智能判断
  • 可以配置白名单机制
  • 支持手动解封和审计日志
  • 通过合理的阈值配置,可以最大程度避免误封

误解四:技术门槛高,难以使用

错误认知:认为这种系统需要深厚的网络安全知识才能部署。

实际情况

  • 设计初衷就是简单:正是因为常规蜜罐太专业,才设计了RDDOS
  • 提供详细的配置文档和快速开始指南
  • 支持一键部署脚本
  • 配置文件化,无需编程知识
  • 提供Web管理界面,可视化操作
  • 普通开发者也能快速上手

4. 这个概念实际上是怎么回事儿?

技术架构

RDDOS系统由以下几个核心组件构成:

4.1 TCP连接监听层

// 监听指定端口,捕获所有连接
tcp_address: ":8080"

系统在TCP层监听连接,在SYN握手完成后立即获取客户端IP地址。这是防护的第一道防线。

4.2 IP记录与分析层

系统会记录每个IP的:

  • 访问次数
  • 访问时间
  • 连接频率
  • 地理位置信息(可选)

这些数据存储在SQLite数据库中,用于后续的分析和决策。

4.3 防护策略层

系统提供多种防护策略:

策略说明适用场景
normal正常处理连接测试和调试
rst发送RST包断开连接快速释放资源
drop直接丢弃连接消耗攻击者资源
flood向客户端发送垃圾数据消耗攻击者带宽
reverse_flood反向洪水攻击对攻击者实施反击
adaptive自适应策略根据攻击强度自动调整

4.4 自适应策略详解

自适应策略是RDDOS的核心创新:

访问1-2次  → 正常处理(可能是误触)
访问3-5次  → RST断开(轻度可疑)
访问6-10次 → 丢弃连接(中度威胁)
访问10+次  → 反向洪水攻击(确认攻击)

这种渐进式的响应策略,既避免了误伤,又能有效应对真正的攻击。

4.5 防火墙集成层

当检测到攻击时,系统会自动:

  1. 添加到拒绝列表:在应用层记录攻击IP
  2. 调用防火墙API:通过SSH连接到防火墙设备
  3. 添加封禁规则:在防火墙层面永久封禁攻击IP
  4. 发送通知:通过飞书等渠道通知管理员

支持的防火墙类型:

  • 华为防火墙(企业级)
  • MikroTik路由器(RouterOS)
  • Linux iptables(服务器级)

4.6 威胁情报集成层

检测到攻击IP后,系统自动提交到blackip系统进行汇总分析,然后提供给其他安全系统(如长亭科技WAF)作为黑名单IP情报。

工作流程

RDDOS检测攻击 → 提交到blackip → 数据汇总分析 → 提供给WAF等系统

4.7 工作流程

连接建立 → IP记录 → 策略判断 → 执行防护
                ↓
           达到阈值?
                ↓
    防火墙封禁 → 提交到blackip → 通知管理员

核心创新:反向洪水攻击

这是RDDOS最具争议也最具创新性的特性,也是"反击"理念的直接体现。

设计动机
被入侵后的心情低落,让我产生了"反击"的想法。为什么只能被动防御?为什么攻击者可以肆无忌惮地扫描和攻击,而防御者只能承受?讨厌攻击者

工作原理

  1. 检测到攻击IP后,建立TCP连接
  2. 向攻击者持续发送大量数据(可配置大小,如1MB、10MB)
  3. 消耗攻击者的带宽和系统资源
  4. 迫使攻击者主动断开连接

效果

  • 攻击者需要消耗资源来接收这些数据
  • 如果攻击者使用代理或VPN,会消耗其代理资源
  • 形成"攻击成本",降低攻击意愿
  • 心理满足:让防御者感受到反击的力量

伦理考量

  • 只在自己的服务器上运行
  • 只对主动连接自己的IP进行响应
  • 这是合法的自我防护行为
  • 关键:只防护自己的资产,不主动攻击他人

5. 正解这个概念有什么意义?

5.1 理论意义:重新定义攻防关系

传统观念认为:防御是被动的,攻击是主动的。

RDDOS告诉我们:防御也可以是主动的,可以主动识别、主动反击、主动学习

这不仅仅是技术层面的创新,更是安全思维的转变:

  • 从"承受"到"反击":不再被动承受攻击,而是主动反击。这是从被入侵的痛苦中诞生的理念
  • 从"人工"到"自动":自动化程度大幅提升,减少人工干预。不需要24小时盯着日志
  • 从"单一"到"多层":应用层、网络层、防火墙层全方位防护。WAF + RDDOS 形成完整防护体系
  • 从"复杂"到"简单":不需要专业的安全知识,普通开发者也能部署和使用

5.2 实践意义:降低防护成本

成本结构对比

项目传统防护RDDOS防护
硬件成本需要专用设备普通服务器即可
服务成本需要购买CDN/云防护开源免费
人力成本需要专业运维自动化程度高
资源消耗防御方承担攻击方承担

ROI分析

  • 部署成本低:一台普通服务器即可
  • 维护成本低:自动化运行,无需频繁干预
  • 效果显著:能够有效阻止大部分扫描和攻击

5.3 战略意义:提升安全水位

对于个人开发者和小型企业:

  1. 降低门槛:不再需要昂贵的商业防护服务
  2. 自主可控:完全掌握防护逻辑,可以根据需求定制
  3. 学习价值:通过部署和使用,深入理解网络安全原理

对于安全研究人员:

  1. 研究平台:可以研究攻击模式和防护策略
  2. 实验环境:可以测试不同的防护方案
  3. 数据收集:可以收集攻击数据进行分析

5.4 威胁情报价值:从单点防护到生态协同

RDDOS收集攻击者IP,提交到blackip系统汇总分析,然后提供给其他安全系统(如长亭科技WAF)作为黑名单IP情报。

协同效应

  • 多个RDDOS实例的数据汇总,形成更全面的威胁视图
  • 一个系统发现的攻击者,其他系统可以提前防护
  • 多源数据交叉验证,提高威胁情报的准确性

实际价值

  • 个人开发者:享受整个生态的威胁情报
  • 企业用户:形成内部威胁情报网络
  • 安全社区:共享威胁情报,共同提升安全水位

6. 如何正确使用这个概念?

6.1 适用场景

✅ 推荐场景

  1. 蜜罐系统(核心场景)

    • 这是RDDOS最初的设计场景:一个简单的蜜罐,对互联网主动暴露
    • 用于诱捕攻击者,收集攻击数据
    • 配置强制封禁模式,一次连接即封禁
    • 完全禁止访问的端口
    • 关键:只要有人访问这个端口,就说明有问题,因为这个端口根本不是正常的服务端口
  2. 内部服务防护

    • 不应该被外部访问的服务
    • 需要严格控制的端口
    • 开发测试环境
    • 配合WAF使用,形成多层防护
  3. 威胁情报收集

    • 收集攻击者IP,提交到blackip系统
    • 参与威胁情报生态,为其他系统提供数据
    • 享受整个生态的威胁情报,提前防护
  4. 学习研究

    • 学习网络安全原理
    • 研究攻击模式
    • 测试防护策略
    • 了解攻击者的行为模式

⚠️ 谨慎使用场景

  1. 对外服务

    • 需要允许正常用户访问
    • 建议使用阈值封禁模式
    • 配置合理的白名单
  2. 生产环境

    • 需要充分测试
    • 配置监控和告警
    • 准备应急响应方案

❌ 不适用场景

  1. 高流量网站

    • 可能影响正常用户体验
    • 建议使用专业的CDN和云防护
  2. 合规要求严格的场景

    • 需要经过法律和合规审查
    • 确保符合相关法规要求

6.2 配置建议

蜜罐模式(推荐)

{
  "max_connections_per_ip": 1,
  "rate_limit_count": 10,
  "response_strategy": "dr",
  "firewall_enabled": true,
  "firewall_force_block_on_attack": true
}

特点:一次连接即封禁,适合非正常服务端口。配合WAF使用,保护真实服务。

生产环境模式

{
  "max_connections_per_ip": 3,
  "rate_limit_count": 100,
  "response_strategy": "adaptive",
  "firewall_enabled": true,
  "firewall_force_block_on_attack": false,
  "firewall_block_threshold": 5
}

特点:基于访问次数阈值判断,自适应策略,避免误伤。

开发测试模式

{
  "max_connections_per_ip": 5,
  "rate_limit_count": 200,
  "response_strategy": "normal",
  "firewall_enabled": false
}

特点:不启用防火墙封禁,正常处理连接。

6.3 部署步骤

  1. 环境准备

    # 确保有Go环境
    go version
    
    # 克隆或下载项目
    git clone <repository>
  2. 配置调整

    # 编辑配置文件
    vim config.json
    
    # 根据场景选择合适的配置模式
  3. 编译构建

    # 静态链接构建(推荐)
    ./build_all.sh static
  4. 部署运行

    # 使用systemd服务
    sudo systemctl start rddos
    
    # 或直接运行
    sudo ./rddos
  5. 监控验证

    # 查看日志
    tail -f /var/log/rddos.log
    
    # 检查防火墙规则
    # MikroTik
    /ip firewall address-list print where list=blackip
    
    # Linux
    iptables -L RDDOS-BLOCK -n -v
    
    # 检查黑名单API提交情况
    # 查看日志中的黑名单API相关记录
    tail -f /var/log/rddos.log | grep "黑名单API"
  6. 配置威胁情报集成(推荐)

    {
      "blacklist_api_enabled": true,
      "blacklist_api_url": "https://blackip.op123.ren/api/blacklist/",
      "blacklist_api_key": "your-api-key"
    }

6.4 最佳实践

  1. 测试环境验证

    • 在测试环境充分测试后再部署到生产
    • 验证各种配置组合的效果
  2. 配置白名单

    • 在防火墙层面配置管理IP白名单
    • 避免封禁自己的管理IP
  3. 启用监控

    • 启用飞书等通知渠道
    • 及时了解封禁情况
  4. 定期审查

    • 定期检查封禁IP列表
    • 清理误封的IP
  5. 启用威胁情报共享

    • 配置blacklist_api_enabled为true
    • 参与威胁情报生态,享受整个生态的威胁情报
  6. 备份配置

    • 修改配置前先备份
    • 保留配置变更记录

7. 错误使用这个概念有什么可怕之处?

7.1 法律风险

风险一:误用为攻击工具

错误行为

  • 在他人服务器上部署RDDOS
  • 使用RDDOS主动攻击他人
  • 利用RDDOS进行网络犯罪

法律后果

  • 可能构成计算机犯罪
  • 违反《网络安全法》
  • 面临刑事责任

正确做法

  • 只在自己的服务器上部署
  • 只防护自己的资产
  • 不主动攻击他人

风险二:过度反击

错误行为

  • 配置过大的反向洪水数据量
  • 对正常用户实施反击
  • 造成他人网络资源耗尽

法律后果

  • 可能构成民事侵权
  • 需要承担赔偿责任

正确做法

  • 合理配置反击参数
  • 设置合理的阈值
  • 配置白名单机制

7.2 技术风险

风险一:误封正常用户

错误配置

{
  "firewall_force_block_on_attack": true,  // 强制封禁
  "firewall_block_threshold": 1            // 阈值过低
}

后果

  • 正常用户可能被误封
  • 影响业务正常运行
  • 需要人工干预解封

正确做法

  • 生产环境使用阈值模式
  • 设置合理的阈值(建议3-5次)
  • 配置白名单

风险二:资源耗尽

错误配置

{
  "reverse_flood_size": 104857600,  // 100MB,过大
  "reverse_flood_delay": "100ms"    // 延迟过小
}

后果

  • 服务器带宽被耗尽
  • 可能影响其他服务
  • 服务器资源被占用

正确做法

  • 合理配置数据大小(1-10MB)
  • 设置合理的延迟(500ms-2s)
  • 监控资源使用情况

风险三:防火墙设备压力

错误配置

{
  "firewall_force_block_on_attack": true,
  "firewall_devices": [/* 多个设备 */]
}

后果

  • 防火墙设备频繁添加规则
  • 可能影响防火墙性能
  • 规则表可能溢出

正确做法

  • 使用阈值模式减少封禁频率
  • 定期清理过期规则
  • 监控防火墙设备状态

7.3 业务风险

风险一:影响正常业务

如果在对外的生产服务上错误配置:

  • 强制封禁模式:可能误封正常用户
  • 阈值过低:正常用户可能被误判为攻击
  • 策略过激:可能影响用户体验

正确做法

  • 生产环境谨慎使用
  • 充分测试后再部署
  • 准备应急响应方案

风险二:安全漏洞

如果系统本身存在安全漏洞:

  • 配置泄露:API密钥、密码等敏感信息泄露
  • 权限问题:系统权限配置不当
  • 代码漏洞:可能存在远程执行等漏洞

正确做法

  • 定期更新系统
  • 使用强密码
  • 限制系统权限
  • 定期安全审计

7.4 伦理风险

风险:滥用技术

虽然RDDOS是防御工具,但如果被滥用:

  • 报复性攻击:对攻击者实施过度反击
  • 恶意竞争:利用技术进行不正当竞争
  • 隐私侵犯:收集和滥用用户数据

正确做法

  • 遵守法律法规
  • 尊重他人权益
  • 合理使用技术
  • 保护用户隐私

8. 这个概念与什么其他重要的概念有重要的联系?

8.1 与DDoS的关系:攻防的镜像

DDoS(Distributed Denial of Service):分布式拒绝服务攻击

  • 目标:通过大量请求耗尽目标服务器资源
  • 方式:利用分布式网络发起攻击
  • 效果:使目标服务不可用

RDDOS(Reverse DDoS):反向DDoS防护

  • 目标:识别并反击攻击者
  • 方式:对攻击者实施反向打击
  • 效果:消耗攻击者资源,降低攻击意愿

关系

  • RDDOS是DDoS的"镜像":同样的技术原理,相反的应用方向
  • 理解DDoS攻击原理,有助于设计更好的RDDOS防护策略
  • 两者都涉及资源消耗,但成本承担方不同

8.2 与防火墙的关系:多层防护体系

传统防火墙

  • 在网络层进行流量过滤
  • 基于规则进行封禁
  • 需要手动或半自动管理

RDDOS + 防火墙

  • RDDOS在应用层进行检测和决策
  • 自动调用防火墙API添加规则
  • 形成应用层+网络层的多层防护

协同效应

  • 检测层:RDDOS在应用层快速检测攻击
  • 执行层:防火墙在网络层执行封禁
  • 持久化:防火墙规则持久化,重启后仍然有效

8.2.1 与WAF的关系:完整防护体系

WAF + RDDOS 的完整方案(被入侵后的实际部署方案):

  1. WAF保护真实服务:在真实服务前端部署WAF,过滤恶意请求
  2. RDDOS作为蜜罐诱捕:部署非正常服务端口,诱捕攻击者

协同效应

  • WAF保护真实服务,过滤已知攻击
  • RDDOS诱捕未知攻击者,提前发现威胁
  • 防火墙在网络层执行封禁,持久化防护

8.3 与蜜罐的关系:主动诱捕

传统蜜罐:太专业、太复杂,普通开发者难以使用。

RDDOS作为简单蜜罐

  • 设计初衷:常规蜜罐太专业,需要一个简单的方案
  • 对互联网主动暴露非正常服务端口
  • 任何访问这个端口的IP都是可疑的,立即封禁
  • 配合WAF使用:WAF保护真实服务,RDDOS诱捕攻击者

关键优势:简单、直接、有效,不需要专业的安全知识

8.4 与速率限制的关系:防护的层次

速率限制(Rate Limiting)

  • 限制单个IP的请求频率
  • 防止资源耗尽
  • 通常基于时间窗口

RDDOS的速率限制

  • 限制每个IP的连接数
  • 限制时间窗口内的请求数
  • 作为防护的第一道防线

关系

  • 速率限制是RDDOS的基础组件
  • 两者结合形成多层次的防护
  • 速率限制防止资源耗尽,RDDOS进行主动反击

8.5 与自适应安全的关系:智能防护

自适应安全(Adaptive Security)

  • 根据威胁动态调整防护策略
  • 学习攻击模式
  • 自动优化防护效果

RDDOS的自适应策略

  • 根据访问次数自动选择策略
  • 从轻度响应到重度反击
  • 避免误伤,提高效率

关系

  • RDDOS体现了自适应安全的理念
  • 可以根据攻击强度动态调整
  • 未来可以加入机器学习,实现真正的自适应

8.6 与零信任的关系:最小权限原则

零信任(Zero Trust)

  • 不信任任何连接
  • 验证所有访问
  • 最小权限原则

RDDOS的零信任实践

  • 不信任任何主动连接
  • 记录和分析所有连接
  • 对可疑连接立即采取行动

关系

  • RDDOS体现了零信任的理念
  • 对所有连接保持警惕
  • 通过行为分析判断信任度

8.7 与安全运营的关系:自动化响应

安全运营(SecOps)

  • 安全事件的检测、响应、恢复
  • 需要快速响应能力
  • 自动化程度要求高

RDDOS的自动化

  • 自动检测攻击
  • 自动执行防护
  • 自动通知管理员

关系

  • RDDOS是安全运营自动化的一部分
  • 减少人工干预,提高响应速度
  • 可以集成到更大的安全运营平台

8.8 与威胁情报的关系:从单点防护到生态协同

RDDOS收集攻击者IP,提交到blackip系统汇总分析,然后提供给其他安全系统(如长亭科技WAF)作为黑名单IP情报。

工作流程

RDDOS检测攻击 → 提交到blackip → 汇总分析 → WAF导入黑名单 → 提前拦截

协同效应

  • 多个RDDOS实例的数据汇总,形成更全面的威胁视图
  • 一个系统发现的攻击者,其他系统可以提前防护
  • 多源数据交叉验证,提高威胁情报的准确性

实际价值

  • 个人开发者:享受整个生态的威胁情报
  • 企业用户:形成内部威胁情报网络
  • 安全社区:共享威胁情报,共同提升安全水位

结语:从被入侵到主动反击

回到2025年9月那个被入侵的下午。如果当时有RDDOS,我就能:

  1. 提前发现:在攻击者真正入侵之前,就知道有人在扫描我的服务器
  2. 主动反击:不再被动承受,而是让攻击者付出代价
  3. 简单部署:不需要专业的安全知识,普通开发者也能使用
  4. 心理满足:从被动挨打到主动反击,这种转变带来的不仅仅是技术上的提升

正如写作之难在于"将网状的思想,通过树状的句法,用线性的文字展开",理解RDDOS也需要这样的过程:

  1. 网状的思想:RDDOS涉及网络安全、系统设计、攻防对抗、情感驱动等多个领域
  2. 树状的句法:通过8个问题构建清晰的知识框架
  3. 线性的文字:用一篇文章串联起所有概念

创新 = 旧元素 + 新组合 + 真实痛点

RDDOS的创新不在于发明了新技术,而在于:

  • 旧元素:TCP监听、IP记录、防火墙管理、速率限制
  • 新组合:将这些元素组合成主动防护系统
  • 真实痛点:从被入侵的痛苦中诞生,解决真实的安全问题
  • 新价值:改变了攻防成本结构,提升了防护效率,更重要的是让防御者不再被动

信息输入量的竞争

理解RDDOS,不仅仅是学习一个工具,更是:

  • 输入新的安全防护思维:从被动到主动
  • 获得多元的视角看待安全问题:技术 + 情感 + 实践
  • 具备更深的洞察力分析攻防关系:理解攻击者的动机和行为

我的建议

如果你也遇到过类似的情况,或者担心服务器安全:

  1. 第一步:部署WAF,保护真实服务
  2. 第二步:部署RDDOS作为蜜罐,诱捕攻击者
  3. 第三步:监控和分析,了解攻击者的行为模式

希望这篇文章能够帮助你:

  • 理解RDDOS诞生的真实背景和设计理念
  • 正确理解RDDOS的概念和原理
  • 避免常见的误解和误用
  • 在实际场景中合理应用
  • 与其他安全概念建立联系

记住:技术本身是中性的,关键在于如何使用。RDDOS是强大的防护工具,需要负责任地使用。只有在合法、合规、合理的前提下,才能真正发挥其价值。

如果你也经历过被入侵的痛苦,希望RDDOS能帮助你从被动防御转向主动反击。这不是报复,而是自我保护。


作者注:本文基于RDDOS开源项目编写,旨在帮助读者正确理解反向DDoS防护的概念和应用。技术讨论欢迎,但请遵守法律法规,合理使用技术。

一个运维,除了需要掌握系统软硬件系统的工作原理外,对于小工具的需求与泥瓦匠、水电暖工人对于改锥的需求是类似的。

近几个月使用 cursor 完成了一些开发工作。
加强网络防护能力,编写了 rddos,意思是反向 ddos。这个工具可以监听某一个 tcp 端口,通过让互联网流量扫描,然后直接返回给一串定义好的文字,并记录下攻击 ip 地址。谈到 ddos,有点让人讨厌的意思。但是被某些机构扫描,以至于暴露了本不该暴露的目标,让黑客或者监察机构发现就没有好果子吃了。所在开发 rddos 是在被搞了一把之后的结果。目前,rddos 除了可以发现攻击来源,还可以向安全中心报告,并实现记录以及历史分析,也可以发给 ssh 服务端。ssh 服务端可以是一个 linux,也可以是 mikrotik 等软路由,还可以是云平台的安全组,实现及时封禁攻击 IP 。

在一家公司工作久了,难免各种网站链接或者系统入口地址,没有上百也会有几十个,本身管理是个问题,就更别提要及时找到了。一开始使用浏览器的书签功能,搭配Floccus 以及坚果云实现了书签同步。虽然用起来还行,但是跨浏览器以及新电脑的配置真让人捉急。另外,自己是有了书签,但是同事没有也是个麻烦事儿。后来用了一套开源的导航站。配置好后虽然能也能用,但是毕竟不是专门为了办公环境使用的。所以写了一个 smartnavigator 的 flask 程序,采用苹果系统中的 Finder 显示模式,一共就最多三级目录/文件,并且支持网页界面输入即搜索,而且可以用空格隔开搜索关键词层层递进搜索,再加上一个 ESC 清空搜索内容返回主页面。嗯,用起来还不错。

借鉴 smartnavigator,针对文档也做了一个 smart reb bible。我记得早先学 Linux 技术的时候,经常会有一些红宝书,或者叫做圣经,所以给这个程序起名“聪明的红宝书”。同样的界面以及功能,只是内容不再是链接而是内容。内容支持 markdown 编辑、复制、下载等功能。早先,使用 obsidian 写了大量内容,对于常用的 Linux 命令以及方案,采用飞书的表格进行了二维处理。这次用“聪明的红宝书”重新来过一遍,搜索定位一顿操作十分舒服了。

以上是近一年来使用 cursor 辅助运维内容的一些案例。
简简单单记录一下。

早上买完早点骑车时,接到物联网小程序后台维护客户的反馈——系统用不了了。我之前提前准备了重启服务的脚本,赶紧执行后系统恢复正常,但心里纳闷为啥会突然出问题。

查流量图发现,凌晨3点左右流量直接降到0,和系统故障时间对上了;再看Linux服务器的uptime,当时9点多,服务器刚启动6个多小时,刚好是凌晨3点重启过的样子。我立刻给阿里云提了工单,工程师说云主机没异常,让我查查运维控制台的定时任务。一查才发现,客户那边有个凌晨3点的自动重启任务(说是为了释放Java内存泄露的内存),但今天重启后程序没自动启动,才导致了故障。最后我跟客户说明情况,把这个定时任务关了。