GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息
GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息一、新闻概述1. 标题GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息2. 发布时间2026 年 3 月 22 日3. 来源Tom's Hardware二、核心内容1. 事件摘要A. 主要内容专注于隐私保护的 Android 分支项目 GrapheneOS 正式声明，将不会遵守新兴的年龄验证法律，拒绝在系统设置时收集用户年龄数据。B. 核心亮点GrapheneOS 明确表示永远不会要求提供个人信息、身份证明或账户宁可放弃某些地区的市场，也不妥协隐私原则多个国家和地区正在推进类似年龄验证法律2. 关键信息A. 涉及法律巴西 Digital ECA（Law 15.211）：已生效，单次违规罚款高达 5000 万雷亚尔（约 950 万美元）加利福尼亚州 Digital Age Assurance Act（AB-1043）：2027 年 1 月 1 日生效科罗拉多州 SB26-051：已通过州参议院B. 罚款金额加州：过失违规每名受影响儿童 2500 美元，故意违规 7500 美元巴西：每次违规最高 5000 万雷亚尔C. 涉及产品GrapheneOS 操作系统及其相关服务3. 背景介绍A. GrapheneOS 简介GrapheneOS 是一个专注于隐私和安全保护的 Android 分支操作系统，由加拿大非营利组织 GrapheneOS Foundation 开发。B. 法律背景全球多国正在推进要求操作系统收集用户年龄数据的立法，理由是保护儿童免受不当内容影响。三、详细报道1. 主要内容A. GrapheneOS 官方声明GrapheneOS 在 X 平台发布声明：GrapheneOS 将保持全球任何人可用，无需提供个人信息、身份证明或账户。GrapheneOS 和我们的服务将继续在国际上提供。如果 GrapheneOS 设备因法规无法在某个地区销售，那就这样吧。B. 各地法律进展巴西：Digital ECA（Law 15.211）已于 2026 年 3 月 17 日生效，要求操作系统供应商实施年龄验证，违者将面临高额罚款。加利福尼亚州：州长纽瑟姆于 2025 年 10 月签署的 Digital Age Assurance Act（AB-1043）将于 2027 年 1 月 1 日生效。该法律要求每个操作系统供应商在账户设置期间收集用户年龄或出生日期，并通过实时 API 将数据传输给应用商店和开发者。科罗拉多州：SB26-051 于 2026 年 3 月 3 日通过州参议院，包含类似要求。C. 法律管辖权问题GrapheneOS Foundation 是注册的加拿大非营利组织，这些法律并非源自加拿大。但管辖权问题仍存在不确定性。美国联邦检察官曾成功引渡并定罪隐私聚焦的比特币混合器 Samourai Wallet 的开发者，其中一名被告居住在葡萄牙。2. 技术细节A. 年龄验证机制加利福尼亚州的法律不要求照片 ID 或生物特征验证，用户只需在设置过程中自行申报年龄。B. 执法机制加州法律由州总检察长执行，对过失违规每次最高罚款 2500 美元，故意违规每次最高 7500 美元。3. 数据与事实A. 合作伙伴影响摩托罗拉与 GrapheneOS 于 2026 年 3 月 2 日在 MWC 上宣布建立长期合作伙伴关系，将把这款强化操作系统带到未来的摩托罗拉硬件上，结束 GrapheneOS 长期仅支持 Google Pixel 设备的排他性。搭载 GrapheneOS 的摩托罗拉手机预计于 2027 年推出。如果摩托罗拉销售预装 GrapheneOS 的设备，这些设备需要遵守销售市场的当地法规，或者摩托罗拉可能需要限制地理销售范围。B. 其他类似案例GrapheneOS 并非首个拒绝遵守年龄验证法律的公司，也不会是最后一个：开源计算器固件 DB48X 的开发者最近发布法律通知，声明其软件不实施、不能实施也不会实施年龄验证MidnightBSD 更新其许可证，禁止巴西用户使用四、影响分析1. 行业影响A. 技术趋势隐私保护与监管要求之间的冲突日益凸显开源项目和隐私优先的组织面临合规挑战B. 法律趋势多国正在推进类似年龄验证立法监管边界与互联网开放性的冲突加剧2. 用户影响A. 现有用户GrapheneOS 服务将继续国际可用用户隐私保护得到维护B. 潜在用户某些地区的用户可能无法购买预装 GrapheneOS 的设备技术用户仍可自行刷机安装C. 地理限制巴西、加利福尼亚州、科罗拉多州等地区的消费者可能面临购买限制。3. 技术趋势A. 隐私优先更多隐私优先的项目可能采取类似立场去中心化和自托管趋势可能加强B. 监管应对技术行业需要找到平衡隐私保护和合规的方法可能出现技术规避方案五、各方反应1. 官方回应GrapheneOS Foundation 坚持其隐私优先原则，明确表示永远不会要求用户提供个人信息。2. 业内评价A. 批评者观点超过 400 名计算机科学家签署公开信，批评这些法律创建了监视基础设施，而无法真正保护儿童，因为自行申报年龄可以轻易绕过。B. 支持者观点支持者认为年龄验证是保护儿童免受不当内容侵害的必要措施。3. 用户反馈A. 正面评价用户赞赏 GrapheneOS 坚持隐私原则社区对宁可不卖也不妥协的立场表示支持B. 关注点用户担心地理限制可能导致设备获取困难担心其他隐私项目可能面临类似压力六、相关链接1. 官方公告GrapheneOS 官方 X 账户声明2. 相关报道Tom's Hardware 原文报道加利福尼亚州 AB-1043 法案全文3. 技术文档GrapheneOS 官方网站Digital ECA 法律文本参考资料GrapheneOS refuses to comply with new age verification laws for operating systems
维基百科再度拉黑 Archive.today，删除 69.5 万条存档链接一、新闻概述1. 标题维基百科再度拉黑 Archive.today：利用访问者浏览器发动 DDoS 攻击2. 发布时间2026 年 2 月 20 日3. 来源维基百科社区共识、Solidot、IT之家等多家媒体报道二、核心内容1. 事件摘要A. 主要内容英文版维基百科编辑达成共识，决定将网页存档网站 Archive.today 及其镜像站点（archive.is、archive.ph）列入黑名单，并清理分散在约 40 万个页面中的 69.5 万条引用链接。B. 核心亮点维基百科史上最大规模的链接清理行动之一Archive.today 被指控利用访问者浏览器对持异见者发动 DDoS 攻击该网站还涉嫌冒用他人身份、篡改存档内容2. 关键信息A. 涉及数据受影响页面：约 40 万个待删除链接：约 69.5 万条DDoS 攻击频率：每 300 毫秒发送一次请求B. 涉及服务Archive.today 主站archive.is、archive.ph 等镜像站点CAPTCHA 验证页面（被植入攻击代码）C. 事件时间线2023 年 8 月：博主发表调查文章2025 年 10 月：FBI 发出传票2026 年 2 月：DDoS 攻击曝光2026 年 2 月 20 日：维基百科正式拉黑3. 背景介绍A. Archive.today 简介Archive.today（又称 archive.is 或 archive.ph）是一个私人资助的网页存档网站，成立于 2012 年。与互联网档案馆的 Wayback Machine 不同，该服务采用用户主动提交的方式存档网页，不遵守 Robots 排除标准。B. 历史争议2013-2016 年：曾被维基百科拉黑，原因包括僵尸网络和链接垃圾2015 年：封锁芬兰 IP 地址，避免与政府纠纷被中国、哈萨克斯坦封锁三、详细报道1. DDoS 攻击事件A. 事件起因2023 年 8 月，博主 Jani Patokallio 发表文章，利用公开信息调查 Archive.today 幕后运营者的身份，文章点击量约 1 万次。2025 年 10 月，FBI 向域名注册商 Tucows 发出传票，要求提供 Archive.today 注册者信息。媒体报道时引用了 Patokallio 的博客，称 Archive.today 创始人可能来自俄罗斯。B. 攻击手段Archive.today 向 Patokallio 发送邮件要求撤下文章（被 Gmail 归类为垃圾邮件）。在未获回应后，该网站在 CAPTCHA 验证页面中嵌入了恶意代码。攻击原理：graph LR A[用户访问 Archive.today] --> B[弹出 CAPTCHA 验证] B --> C[页面加载恶意 JavaScript] C --> D[每 300ms 发送请求] D --> E[目标博客服务器] E --> F[带宽耗尽/费用增加]只要用户保持 CAPTCHA 页面打开，恶意代码就会每隔 300 毫秒向 Patokallio 的博客发送一次请求，通过大量访问者的浏览器形成分布式拒绝服务攻击。C. 威胁与骚扰Archive.today 运营者对 Patokallio 进行辱骂和威胁，声称要开发与他名字相关的 AI 色情内容。2. 其他恶意行为A. 篡改存档内容Archive.today 被发现在存档页面中擅自插入与持异见者相关的内容，破坏了存档作为可靠证据的可信度。B. 冒用身份该网站涉嫌冒用他人身份进行操作。3. 维基百科的决策A. 社区讨论DDoS 攻击事件曝光后，维基百科志愿者发起了关于是否将 Archive.today 加入黑名单的讨论（RFC 5）。B. 最终决定维基百科编辑达成共识：立即弃用 Archive.today将其添加到垃圾黑名单创建编辑过滤器阻止添加新链接删除所有指向该站点的约 69.5 万条链接四、影响分析1. 行业影响A. 网页存档生态Archive.today 曾被视为仅次于互联网档案馆的第二重要网络存档服务，特别适用于：收费网站的存档大量使用 JavaScript 的页面被 Robots.txt 阻止的页面此次事件将严重影响其可信度和使用率。B. 存档服务信任危机用户对第三方存档服务的信任度下降，可能促使用户转向：互联网档案馆 Wayback Machine自建存档方案Perma.cc 等学术存档服务2. 用户影响A. 维基百科读者约 40 万个页面的引用链接失效部分历史证据难以追溯需要寻找替代存档来源B. 数据保存爱好者失去一个重要的存档工具对存档服务的可靠性和中立性产生质疑3. 技术趋势A. CAPTCHA 安全性此次事件暴露了 CAPTCHA 页面可能被滥用的安全风险，网站运营者需要更严格地验证第三方脚本的安全性。B. 存档服务规范化事件可能推动存档服务行业建立更明确的道德准则和透明度要求。五、各方反应1. 官方回应维基百科社区通过编辑共识机制做出了此次决定，体现了社区治理的运作方式。2. 业内评价A. 数据保存社区Reddit 等平台的 DataHoarder 社区对此进行了激烈讨论。部分用户认为：Archive.today 的功能确实独特且有用但其恶意行为不可接受维基百科的决定合理B. 安全专家安全专家指出，利用访问者浏览器发动攻击是一种隐蔽但危害巨大的手段，难以被传统防御措施检测。3. 替代方案A. 互联网档案馆遵守 Robots 标准主动爬取更高的可信度B. Perma.cc专注于学术和法律引用更严格的内容审核非营利性质C. 自建方案使用 wget、httrack 等工具完全控制存档过程避免第三方风险六、相关链接1. 官方公告维基百科 RFC 讨论：Wikipedia:Requests_for_comment/Archive.is_RFC_5维基百科黑名单政策2. 相关报道Solidot：Archive.today 对博主发动 DDoS 攻击，维基百科考虑将其屏蔽Ars Technica：Wikipedia might blacklist archive.today after site maintainer DDoSed a blogIT之家：网页存档站点 Archive.today 再度被维基百科拉黑3. 技术文档Archive.today Wikipedia 条目互联网档案馆 Wayback Machine参考资料Archive.today - 维基百科Solidot - Archive.today 对博主发动 DDoS 攻击Wikipedia:Requests_for_comment/Archive.is_RFC_5
rathole 入门指南一、概述1. 简介A. 是什么rathole 是一个用 Rust 编写的轻量级、高性能反向代理工具，用于 NAT 穿透。它可以将位于 NAT 后面的设备上的服务暴露到互联网上。与 frp 和 ngrok 类似，rathole 通过一台具有公网 IP 的服务器来中转流量，使内网服务可被外网访问。B. 为什么学解决家庭服务器或 NAS 无法直接访问的问题相比 frp 具有更高的性能和更低的资源占用用 Rust 编写，二进制文件可小至 500KiB，适合嵌入式设备C. 学完能做什么在公网服务器上部署 rathole 服务端在内网设备上配置客户端，将本地服务暴露到公网配置加密传输，保护数据安全热重载配置，无需重启服务二、环境准备1. 系统要求服务器：具有公网 IP 的 Linux 服务器客户端：位于 NAT 后面的设备（家用电脑、NAS 等）操作系统：Linux、macOS、Windows、支持 Docker 的平台2. 安装步骤从官方发布页面下载预编译二进制文件：Linux:wget https://github.com/rathole-org/rathole/releases/download/v0.5.0/rathole-x86_64-unknown-linux-musl.tar.gz tar -xzf rathole-x86_64-unknown-linux-musl.tar.gzDocker:docker pull rapiz1/rathole从源码编译：git clone https://github.com/rathole-org/rathole.git cd rathole cargo build --release3. 验证安装./rathole --version三、核心概念1. 基本术语服务端（Server）：运行在具有公网 IP 的服务器上，监听来自客户端的连接和来自外网的访问请求客户端（Client）：运行在 NAT 后面的设备上，主动连接服务端并注册需要转发的服务Token：服务端和客户端之间用于身份验证的密钥服务（Service）：需要转发的具体应用，如 SSH、Web 服务器等2. 工作原理graph LR A[外网用户] -->|访问公网端口| B[服务端] B <-->|加密通道| C[客户端] C -->|转发请求| D[本地服务]rathole 的工作流程如下：客户端主动连接服务端，并使用 Token 进行身份验证服务端记录客户端注册的服务映射关系外网用户访问服务端的公网端口服务端通过加密通道将流量转发给客户端客户端将流量转发到本地服务四、快速上手1. 基本示例：暴露 NAS 的 SSH 服务场景你有一台位于家庭网络的 NAS，希望从互联网上通过 SSH 访问它。服务端配置创建 server.toml 文件：[server] bind_addr = "0.0.0.0:2333" [server.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" bind_addr = "0.0.0.0:5202"启动服务端：./rathole --server server.toml客户端配置创建 client.toml 文件：[client] remote_addr = "myserver.com:2333" [client.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" local_addr = "127.0.0.1:22"启动客户端：./rathole --client client.toml验证连接ssh -p 5202 myserver.com2. 多服务配置可以在一个配置文件中定义多个服务：客户端配置：[client] remote_addr = "myserver.com:2333" [client.services.ssh] token = "ssh_token" local_addr = "127.0.0.1:22" [client.services.web] token = "web_token" local_addr = "127.0.0.1:8080" [client.services.minecraft] token = "mc_token" local_addr = "127.0.0.1:25565" type = "tcp"服务端配置：[server] bind_addr = "0.0.0.0:2333" [server.services.ssh] token = "ssh_token" bind_addr = "0.0.0.0:5202" [server.services.web] token = "web_token" bind_addr = "0.0.0.0:5203" [server.services.minecraft] token = "mc_token" bind_addr = "0.0.0.0:5204" type = "tcp"3. UDP 服务转发rathole 支持 UDP 协议转发：[client.services.quic] type = "udp" token = "quic_token" local_addr = "127.0.0.1:4433"[server.services.quic] type = "udp" token = "quic_token" bind_addr = "0.0.0.0:4433"五、进阶配置1. 传输层加密rathole 支持三种传输模式：TCP、TLS、Noise。TLS 加密服务端配置：[server.transport] type = "tls" [server.transport.tls] pkcs12 = "identity.pfx" pkcs12_password = "your_password"客户端配置：[client.transport] type = "tls" [client.transport.tls] trusted_root = "ca.pem" hostname = "example.com"Noise Protocol 加密Noise Protocol 是现代的加密协议，无需证书：[client.transport] type = "noise" [client.transport.noise] pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s" local_private_key = "your_base64_key" remote_public_key = "server_base64_key"2. 代理连接客户端可以通过代理连接服务端：[client.transport.tcp] proxy = "socks5://user:passwd@127.0.0.1:1080"支持 HTTP 和 SOCKS5 代理。3. 日志控制通过环境变量控制日志级别：RUST_LOG=error ./rathole config.toml可用级别：error、warn、info、debug、trace默认级别为 info。4. 性能调优从 v0.4.7 开始，rathole 默认启用 TCP_NODELAY，这对延迟敏感的应用（如 RDP、Minecraft 服务器）有益，但会略微降低带宽。如果带宽更重要，可以禁用：[client.transport.tcp] nodelay = false [server.transport.tcp] nodelay = false也可以针对单个服务配置：[client.services.my_service] nodelay = false5. 心跳与重连客户端心跳配置：[client] heartbeat_timeout = 40 retry_interval = 1服务端心跳配置：[server] heartbeat_interval = 30heartbeat_interval：应用层心跳发送间隔，设为 0 禁用heartbeat_timeout：心跳超时时间，必须大于 server.heartbeat_intervalretry_interval：重连服务器的间隔六、部署实战1. systemd 服务配置创建 /etc/systemd/system/rathole-server.service：[Unit] Description=Rathole Server After=network.target [Service] Type=simple User=root ExecStart=/path/to/rathole --server /path/to/server.toml Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target创建 /etc/systemd/system/rathole-client.service：[Unit] Description=Rathole Client After=network.target [Service] Type=simple User=root ExecStart=/path/to/rathole --client /path/to/client.toml Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target启用并启动：systemctl daemon-reload systemctl enable rathole-server systemctl start rathole-server2. Docker 部署服务端：docker run -d \ --name rathole-server \ -p 2333:2333 \ -p 5202:5202 \ -v /path/to/server.toml:/app/server.toml \ rapiz1/rathole --server /app/server.toml客户端：docker run -d \ --name rathole-client \ --network host \ -v /path/to/client.toml:/app/client.toml \ rapiz1/rathole --client /app/client.toml七、性能对比1. 与 frp 的对比rathole 在性能方面相比 frp 有显著优势：吞吐量：HTTP 吞吐量更高连接数：能处理更多并发连接内存占用：显著低于 frp延迟：与 frp 相当2. 性能基准根据官方基准测试结果：HTTP 吞吐量：比 frp 提升 2-3 倍（本地回环测试）TCP 比特率：显著优于 frp内存占用：仅为 frp 的 30-50%需要注意的是，这些测试是在本地回环环境下进行的，反映的是 CPU 限制场景下的性能。实际使用中，网络往往是瓶颈，此时性能提升可能不那么明显。但 rathole 的主要优势在于低资源消耗。3. 资源占用优化rathole 的二进制文件可以编译至约 500KiB，非常适合：路由器等嵌入式设备资源受限的 VPS需要同时运行多个服务的环境八、常见问题1. 连接失败问题：客户端无法连接到服务端排查：检查服务端防火墙是否开放监听端口确认 Token 配置是否一致验证 remote_addr 地址和端口是否正确查看服务端日志是否有连接记录2. 热重载不生效问题：修改配置后服务未生效解决：目前需要重启服务应用新配置HTTP API 配置功能正在开发中3. 性能不佳问题：转发服务变慢排查：检查客户端和服务端的网络延迟确认没有启用不必要的代理尝试调整 TCP_NODELAY 设置检查本地服务本身是否有性能问题参考资料rathole GitHub 仓库rathole 官方文档
JumpServer 连接 192.168.124.48 失败排障复盘一、事件概述1. 事件背景在同一网络环境中，本地与 192.168.124.210 宿主机均可直接 SSH 登录 192.168.124.48，但通过 JumpServer 页面连接同一资产失败，表现为连接超时。2. 影响范围A. 影响对象通过 JumpServer 访问 192.168.124.48 的运维会话。B. 未受影响对象直接从本地或 192.168.124.210 宿主机执行 SSH 到 192.168.124.48。C. 业务影响堡垒机路径不可用，导致统一审计入口受阻，但不影响目标主机自身 SSH 服务可用性。3. 严重程度中等。属于单资产访问异常，但影响堡垒机标准运维路径。二、现象与证据链1. 关键现象A. 主机对比测试192.168.124.210 宿主机到 192.168.124.48:22 可达。JumpServer 的 koko 容器到 192.168.124.48:22 超时。koko 容器到 192.168.124.196:22 正常。B. 抓包结论在 192.168.124.48 抓包可见两类来自 192.168.124.210 的 TCP SYN：一类可得到 SYN-ACK，并完成短连接握手。另一类持续重传 SYN，无任何 SYN-ACK 返回。说明问题并非简单的目标端口关闭，也非全网段 ACL 阻断，而是同源 IP 下不同连接特征被内核策略选择性丢弃。2. 拓扑与路径graph LR U[运维用户] --> J[JumpServer Web] J --> K[koko 容器 192.168.250.7] K --> N[宿主机 NAT 源地址转为 192.168.124.210] N --> T[目标主机 192.168.124.48:22] H[宿主机 192.168.124.210 直接 SSH] --> T三、根因分析1. 直接根因192.168.124.48 开启了已废弃且高风险的内核参数：net.ipv4.tcp_tw_recycle = 1该参数在 NAT 场景下会根据时间戳特征对同源地址连接做严格回收与校验，容易误判并丢弃合法 SYN。2. 为什么只影响 JumpServer 路径A. 共同点两条路径在目标主机侧看到的源地址都可能是 192.168.124.210。B. 差异点JumpServer 通过容器与 NAT 转发，连接时间戳与会话模式和宿主机直连不同，触发 tcp_tw_recycle 的误杀条件，导致 48 不回 SYN-ACK。C. 对照验证关闭 tcp_tw_recycle 后，koko 到 192.168.124.48:22 立即恢复连通，且 SSH 握手可进入认证阶段。四、修复动作1. 立即修复在 192.168.124.48 执行：sysctl -w net.ipv4.tcp_tw_recycle=02. 持久化修复新增文件 /etc/sysctl.d/99-disable-tcp-tw-recycle.conf：net.ipv4.tcp_tw_recycle = 0加载配置：sysctl -p /etc/sysctl.d/99-disable-tcp-tw-recycle.conf3. 修复后验证docker exec jms_koko nc -vz -w 3 -n 192.168.124.48 22 返回 succeeded。docker exec jms_koko ssh 到 192.168.124.48 已能完成握手并进入认证阶段。五、预防与标准化建议1. 内核参数基线在所有仍运行老内核的主机上禁用 tcp_tw_recycle。建议保留 tcp_tw_reuse 的审慎配置，避免误用高风险参数。2. 变更前检查清单涉及 SSH 异常时，必须做三点对照：宿主机直连、容器路径、目标机抓包。同时采集目标机 sysctl 网络参数，优先排查历史兼容性开关。3. 架构层建议明确 JumpServer 的真实出网路径与源地址模型。对关键资产建立堡垒机链路自动探测，提前发现单点异常。六、结论本次故障并非 JumpServer 平台整体不可达，也非 192.168.124.0/24 网段通断问题，而是目标主机 192.168.124.48 的遗留内核参数 tcp_tw_recycle 在 NAT 场景下触发误杀。参数关闭后，JumpServer 到该资产连接恢复正常。参考资料Linux tcp_tw_recycle 在 NAT 场景的已知问题说明
亲伊朗黑客组织 Handala 声称对美国医疗科技巨头 Stryker 发起攻击
亲伊朗黑客组织 Handala 声称对美国医疗科技巨头 Stryker 发起攻击一、新闻概述1. 标题亲伊朗黑客组织 Handala 声称对美国医疗科技巨头 Stryker 发起攻击2. 发布时间2026 年 3 月 11 日3. 来源KrebsOnSecurity二、核心内容1. 事件摘要A. 主要内容一个与伊朗情报机构有关的黑客激进组织声称对美国医疗科技公司 Stryker 发起了数据擦除攻击。该公司总部位于密歇根州，是一家全球医疗技术企业。B. 核心亮点黑客组织 Handala 声称抹去了超过 200,000 个系统、服务器和移动设备的数据Stryker 位于爱尔兰的最大海外中心超过 5,000 名员工被送回家攻击者可能利用 Microsoft Intune 管理工具执行远程擦除攻击已对美国医院的医疗供应链产生影响2. 关键信息A. 受影响范围Stryker 在 79 个国家的办公室据称被迫关闭爱尔兰总部超过 5,000 名员工受影响超过 200,000 台设备被擦除数据B. 攻击目标公司名称：Stryker行业：医疗和外科设备制造商规模：2025 年全球销售额达 250 亿美元，员工 56,000 人C. 技术手段使用 Microsoft Intune 云管理服务下发远程擦除命令登录页面被篡改为 Handala 组织的标志3. 背景介绍A. 攻击动机Handala 组织在声明中称，此次攻击是对 2 月 28 日导弹袭击伊朗学校事件的报复。据《纽约时报》报道，美国被确认为这次造成至少 175 人死亡（大多数是儿童）的战斧导弹袭击的责任方。B. 组织背景Handala 组织于 2023 年底首次出现，与伊朗情报和国家安全部（MOIS）有关联。Palo Alto Networks 报告称，该组织是 MOIS 关联行动者 Void Manticore 维护的多个网络身份之一。三、详细报道1. 主要内容A. 攻击声明Handala 在 Telegram 上发布的一份冗长声明中声称，已抹去 Stryker 全球网络中超过 200,000 个系统、服务器和移动设备的数据。声明中称：所有获取的数据现在掌握在世界自由人民手中，准备用于人类真正的进步和揭露不公正与腐败。B. 攻击手法根据知情人士透露，攻击者似乎使用了 Microsoft Intune 服务向所有连接设备下发远程擦除命令。Intune 是微软提供的基于云的解决方案，旨在帮助 IT 团队执行安全和数据合规策略，它提供了一个单一的基于 Web 的管理控制台来监控和控制无论位置在哪里的设备。C. 攻击技术分析攻击流程如下：graph TD A[Handala 黑客组织] -->|入侵获取| B[IT 管理权限] B -->|访问| C[Microsoft Intune 控制台] C -->|下发远程擦除命令| D[所有连接的设备] D --> D1[计算机系统] D --> D2[服务器] D --> D3[移动设备] D1 -->|数据被抹除| E[设备显示 Handala Logo] D2 -->|数据被抹除| E D3 -->|数据被抹除| E E --> F[业务全面中断] F --> F1[员工无法工作] F --> F2[医院供应链受阻] F --> F3[在线服务停摆]这种攻击方式与传统恶意软件不同。传统的擦除器攻击通常涉及恶意软件设计，用于覆盖受感染设备上的任何现有数据。但这次案例中，攻击者利用合法的企业管理工具来执行恶意命令。2. 技术细节A. 攻击手段特点利用合法的 IT 管理平台：攻击者没有部署传统恶意软件，而是劫持了企业用来管理设备的 Microsoft Intune 平台大规模远程擦除：通过统一的 Web 管理控制台，可以一次性向全球所有连接设备下发擦除命令设备范围广泛：包括计算机系统、服务器和员工移动设备B. 证据支持Reddit 上关于 Stryker 停机的讨论中，几名自称是 Stryker 员工的用户表示，他们被告知紧急卸载 Intune。这支持了攻击者使用 Intune 执行远程擦除的判断。C. 组织攻击模式Palo Alto Networks 研究人员指出，Handala 的黑客和泄露活动主要集中在以色列，偶尔在服务于特定议程时在该范围之外进行攻击。近期观察到的活动是机会主义的快速而肮脏的攻击，明显专注于供应链入口（例如 IT 服务提供商）以到达下游受害者，随后发布证明帖子以放大可信度和恐吓目标。3. 数据与事实A. 攻击规模声称抹除系统数量：200,000+受影响国家：79 个受影响员工：仅爱尔兰就超过 5,000 人B. 公司影响Stryker 密歇根总部语音信箱称：我们目前正在经历大楼紧急情况，请稍后再试爱尔兰媒体报道：员工现在通过 WhatsApp 沟通以了解何时可以返回工作岗位员工反馈：任何连接网络的设备都停机，所有带有 Microsoft Outlook 的个人手机设备都被擦除C. 组织历史Handala 组织此前还声称对以下攻击负责：约旦的燃料系统攻击以色列能源勘探公司攻击四、影响分析1. 行业影响A. 医疗供应链风险这是一次现实的供应链攻击。一位匿名专家指出，美国几乎所有进行手术的医院都使用他们的设备。当一家主要的医疗设备供应商受到攻击时，整个医疗系统都会受到影响。B. 攻击模式演变从针对特定政治目标的攻击，转向利用供应链的广泛报复性攻击。Palo Alto 指出，Handala 组织专注于供应链入口（如 IT 服务提供商）来攻击下游受害者。C. 地缘政治风险此次攻击展示了网络攻击如何被用作地缘政治报复的工具。攻击者明确将 Stryker 描述为锡安主义根植的公司，这可能指的是该公司 2019 年收购以色列公司 OrthoSpace 的历史。2. 用户影响A. 医疗机构美国一位主要大学医疗系统的医疗专业人员告诉 KrebsOnSecurity，他们目前无法订购通常通过 Stryker 获取的手术用品。这表明攻击已经开始影响医疗保健提供者。B. 应急医疗服务根据马里兰州紧急医疗服务系统研究所 3 月 11 日的备忘录，Stryker 表示部分计算机系统受到全球网络中断的影响。作为响应，许多医院选择断开与 Stryker 各种在线服务的连接，包括 LifeNet。LifeNet 允许护理人员将心电图传输给急诊医生，以便心脏病患者在到达医院时能够加快治疗。为了应对此情况，马里兰州 EMS 医疗主任写道，如果你无法将 12 导联心电图传输到接收医院，应发起无线电咨询并描述心电图上的发现。C. 供应商依赖风险此次事件突显了医疗机构对少数主要供应商的依赖所带来的风险。当这些供应商的 IT 系统受到攻击时，可能会对下游医院的患者护理产生连锁反应。3. 技术趋势A. 管理工具滥用趋势攻击者利用合法的企业管理工具执行恶意操作的趋势正在上升。Microsoft Intune 等平台原本旨在帮助企业管理和保护设备，但如果凭证泄露，它们也可以成为攻击者大规模破坏的工具。B. 攻击者的机会主义策略Palo Alto 指出，近期观察到的活动是机会主义的快速而肮脏的攻击。攻击者专注于找到供应链中的薄弱环节，然后利用这些入口攻击下游目标。五、各方反应1. 官方回应A. Stryker 公司截至报道时，Stryker 尚未发布正式声明，但通过语音信音告知总部大楼紧急情况，建议稍后再试。B. 美国医院协会美国医院协会（AHA）国家顾问 John Riggi 表示，AHA 目前未获悉任何供应链中断情况。Riggi 在一封电子邮件中说：我们意识到有关对 Stryker 进行网络攻击的报告，并正在与医院现场和联邦政府积极交换信息，以了解威胁的性质并评估对医院运营的任何影响。截至目前，我们未获悉此次攻击对美国医院造成的任何直接影响或中断。随着医院评估与 Stryker 相关的服务、技术和供应链，如果攻击持续时间延长，这种情况可能会发生变化。2. 业内评价A. 网络安全专家一位匿名专家指出，这是真实世界的供应链攻击，几乎所有在美国进行手术的医院都使用他们的设备。这表明此次攻击的严重性和广泛影响。B. 安全研究机构Palo Alto Networks 此前曾对 Handala 组织进行过分析，将其与伊朗情报机构联系起来。该组织主要针对以色列，偶尔服务于特定议程时会在范围之外进行攻击。3. 用户反馈A. 员工反馈多名 Stryker 员工在 Reddit 上讨论了此次攻击，透露公司要求他们紧急卸载 Intune。一些员工报告说，他们的个人手机上的 Microsoft Outlook 设备被擦除。B. 医疗机构反应一些医院已选择暂时断开与 Stryker 系统的连接，包括 LifeNet，作为预防措施。另一些医院则保持连接，但正在密切监控情况。六、后续发展1. 持续影响马里兰州 EMS 指示，如果无法传输 12 导联心电图，应改用无线电咨询。这表明医疗机构正在启动备用程序以维持紧急医疗服务。2. 供应链中断风险虽然美国医院协会目前未报告直接供应链中断，但随着医院评估与 Stryker 相关的服务、技术和供应链，如果攻击持续时间延长，这种情况可能会发生变化。3. 攻击范围扩大可能性Handala 组织将 Stryker 描述为锡安主义根植的公司，可能意味着该组织会继续针对与以色列有商业往来的公司进行攻击。七、相关链接1. 官方公告Stryker 尚未发布关于此次攻击的正式公告2. 相关报道Irish Examiner 关于 Stryker 爱尔兰员工被送回家的报道《纽约时报》关于美国对伊朗学校导弹袭击事件的报道3. 技术文档Microsoft Intune 官方文档Palo Alto Networks 关于 Handala 组织的分析报告参考资料Iran-Backed Hackers Claim Wiper Attack on Medtech Firm Stryker
亲伊朗黑客组织 Handala 声称对美国医疗科技巨头 Stryker 发起攻击一、新闻概述1. 标题亲伊朗黑客组织 Handala 声称对美国医疗科技巨头 Stryker 发起攻击2. 发布时间2026 年 3 月 11 日3. 来源TechCrunch二、核心内容1. 事件摘要A. 主要内容一个与伊朗有关的黑客组织声称已经攻入美国医疗科技巨头 Stryker 的服务器，造成全球范围内的系统中断。B. 核心亮点超过 20 万台系统、服务器和移动设备被擦除50 TB 关键数据被提取79 个国家的 Stryker 办事处被迫关闭2. 关键信息A. 攻击规模受影响设备：超过 20 万台数据泄露量：50 TB受影响国家：79 个B. 攻击目标Stryker（美国医疗科技公司，为医院提供医疗设备和技术）C. 攻击动机报复美国对德黑兰 Minab 女孩学校的轰炸，该袭击造成超过 175 人死亡，其中大多数是儿童。3. 背景介绍A. 前置事件美国军方据报道最近对伊朗发动袭击，轰炸了德黑兰的 Minab 女孩学校。B. 相关上下文Handala 黑客组织出现在哈马斯 10 月 7 日对以色列发动攻击之后，其攻击目标包括以色列民用基础设施、海湾地区能源公司以及西方组织。三、详细报道1. 主要内容A. 攻击方式黑客组织通过入侵 Stryker 的服务器，对全球系统进行擦除操作，部分登录页面被替换为黑客组织的 logo。B. 技术手段根据 IBM X-Force Exchange 的情报，Handala 使用多种不断演变的工具包，包括：钓鱼攻击定制擦除恶意软件勒索软件式勒索数据窃取黑客与泄露活动C. 声明内容黑客在 X（原 Twitter）上发布声明称：此次行动是对 Minab 学校惨烈袭击的报复，也是对针对伊朗及其盟友基础设施持续网络攻击的回应。graph TD A[攻击动机] -->|报复美国轰炸德黑兰学校| B[选择目标] B --> C[Stryker 医疗科技公司] C --> D[攻击手段] D -->|钓鱼攻击| E[获取访问权限] D -->|定制擦除恶意软件| F[擦除系统] D -->|数据窃取| G[提取 50TB 数据] E --> H[入侵服务器] H --> F H --> G F --> I[20 万系统被擦除] G --> J[数据泄露] I --> K[79 国家办事处关闭] J --> K2. 技术细节A. 攻击影响Stryker 的 Microsoft 环境遭遇全球网络中断Windows 环境受到严重影响，客户端设备和服务器均受波及用户访问系统和服务的能力受到显著影响B. Stryker 回应公司发言人向 TechCrunch 表示：Stryker 正在经历网络攻击导致的 Microsoft 环境全球网络中断。公司没有发现勒索软件或恶意软件的证据，认为事件已得到控制。团队正在积极工作，尽快恢复系统和运营。C. 业务背景Stryker 为医院生产医疗设备和技术，虽然与近期对伊朗的攻击似乎没有直接联系，但其在以色列设有业务，且去年从美国国防部获得了一份价值 4.5 亿美元的医疗设备供应合同。3. 数据与事实A. Handala 组织特征出现时间：哈马斯 2025 年 10 月 7 日袭击以色列之后攻击重点：制造破坏性和心理影响活动特点：包含意识形态信息、夸大或误导性的入侵声明B. 目标选择Handala 故意针对生命攸关的部门，如医疗和能源领域。四、影响分析1. 行业影响A. 网络安全威胁升级意识形态驱动的网络攻击日益增多医疗等关键基础设施成为攻击目标B. 地缘政治网络战伊朗-美国冲突延伸至网络空间亲伊朗黑客组织针对美国及其盟友企业的攻击增加2. 用户影响A. 医疗服务潜在风险Stryker 作为医疗设备供应商，其系统中断可能影响医院正常运营。B. 数据安全风险50 TB 关键数据被提取，可能涉及敏感医疗信息。C. 全球业务中断79 个国家的办事处关闭，显示攻击的全球范围。3. 技术趋势A. 攻击手段多样化黑客组织使用钓鱼、擦除恶意软件、数据窃取等多种手段。B. 破坏性攻击增加与传统的勒索软件不同，Handala 专注于破坏性擦除和泄露。五、各方反应1. 官方回应A. Stryker 公司已启动业务连续性措施承诺继续为客户提供服务认为事件已得到控制B. 美国网络安全与基础设施安全局（CISA）尚未对 TechCrunch 的置评请求作出回应。2. 业内评价A. IBM X-Force ExchangeHandala 的行动重点在于制造破坏性和心理影响，其活动始终以意识形态信息为特征，并故意针对生命攸关的部门。B. Check Point（以色列网络安全公司）自伊朗战争开始以来，Handala 一直在攻入防御薄弱的系统，进行黑客与泄露活动，并通过精心安排被盗材料的发布时间来最大化压力。3. Handala 组织其他活动A. 人肉搜索网站该组织维护着一个网站，列出并人肉搜索了数十名据称为以色列国防军工作或曾经工作过的以色列人，以及主要的当地国防和监控承包商，如 Elbit Systems 和 NSO Group。B. 以往攻击记录以色列民用基础设施海湾地区能源公司西方组织六、相关链接1. 原始报道TechCrunch 原文：Pro-Iran hacktivist group says it is behind attack on medical tech giant Stryker2. 相关资源IBM X-Force Exchange：威胁组织情报平台Check Point 报告：Handala 组织分析参考资料Pro-Iran hacktivist group says it is behind attack on medical tech giant Stryker
acme.sh 通配符证书验证失败排查复盘一、事件概述1. 事件背景在主机 root@156.226.176.52 上使用 acme.sh 签发 op123.ren 及其多子域通配符证书时，DNS 验证失败，报错提示在 _acme-challenge.n9e.op123.ren 处未找到 TXT 记录。2. 影响范围A. 影响功能无法为以下域名签发或续期证书：op123.ren、.op123.ren、.ngrok.op123.ren、.tools.op123.ren、.atzlinux.op123.ren、.api.op123.ren、.mcp.op123.ren、*.n9e.op123.ren。B. 影响时长自执行命令至根因确认并给出修复方案为止。C. 严重程度证书无法签发会导致上述域名无法使用有效的 HTTPS，属配置类问题，修复后即可恢复。3. 执行命令与报错执行命令为：/root/.acme.sh/acme.sh --issue -d op123.ren -d "*.op123.ren" \ -d "*.ngrok.op123.ren" -d "*.tools.op123.ren" -d "*.atzlinux.op123.ren" \ -d "*.api.op123.ren" -d "*.mcp.op123.ren" -d "*.n9e.op123.ren" \ --dns dns_tencent --challenge-alias sddts.cn --force报错摘要：Invalid status. Verification error details: No TXT record found at _acme-challenge.n9e.op123.renRemoving DNS records 时仅删除了 _acme-challenge.sddts.cn 的 TXT 记录伴随 libcurl error code 3 等次要错误二、事件时间线1. 问题发生用户执行上述 acme.sh 命令，使用腾讯云 DNS API（dns_tencent）与挑战别名（challenge-alias sddts.cn），期望在 sddts.cn 所在 DNS 写入一条 TXT 完成所有域名验证。2. 问题定位通过分析报错与 acme.sh 官方文档可知：使用 --challenge-alias 时，acme.sh 只会把验证用 TXT 写在 _acme-challenge.sddts.cnLet's Encrypt 仍会按域名逐个查询 _acme-challenge.<域名>因此必须在 op123.ren 的 DNS 中，为每个参与签发的（子）域名预先配置 CNAME：_acme-challenge.<该域名> 指向 _acme-challenge.sddts.cn报错指向 _acme-challenge.n9e.op123.ren，说明该名的 CNAME 缺失或指向错误。3. 根因确认用户执行 dig 验证：dig _acme-challenge.n9e.op123.ren CNAME +short返回结果为：_acmhe-challenge.sddts.cn.（多了一个字母 h）。正确目标应为 _acme-challenge.sddts.cn.。CNAME 目标拼写错误，导致 Let's Encrypt 跟随 CNAME 后查询的是 _acmhe-challenge.sddts.cn 的 TXT，而 acme.sh 实际写入的是 _acme-challenge.sddts.cn，因此验证失败。4. 解决方案在 op123.ren 的 DNS 中，将 _acme-challenge.n9e.op123.ren 的 CNAME 目标从 _acmhe-challenge.sddts.cn. 修改为 _acme-challenge.sddts.cn.，等待解析生效后重新执行 acme.sh 签发命令。三、问题分析1. 直接原因Let's Encrypt 在查询 _acme-challenge.n9e.op123.ren 时，通过 CNAME 被指向 _acmhe-challenge.sddts.cn，在该处无法获得 acme.sh 写入的 TXT（TXT 实际在 _acme-challenge.sddts.cn），因此报「No TXT record found at _acme-challenge.n9e.op123.ren」。2. 根本原因（5 Whys 分析）A. 为什么会出现这个问题？CNAME 记录的目标主机名配置错误，写成了 _acmhe-challenge.sddts.cn 而非 _acme-challenge.sddts.cn。B. 为什么没有在首次配置时发现？多子域、多 CNAME 时，易在手工添加或复制时产生拼写错误，且 DNS 配置后未逐条用 dig 校验 CNAME 目标是否正确。C. 为什么其他子域可能未报错？若其他子域（如 op123.ren、ngrok、tools 等）的 _acme-challenge 的 CNAME 已正确指向 _acme-challenge.sddts.cn，则仅 n9e.op123.ren 会验证失败，与报错仅指向 n9e 一致。3. 深层反思使用 DNS alias 模式时，每个域名/子域都依赖一条正确的 CNAME，漏配或写错任一条都会导致该域名验证失败。建议在批量配置 CNAME 后，用脚本或逐条 dig 检查每条 _acme-challenge.<子域> 的 CNAME 是否指向 _acme-challenge.sddts.cn.。四、解决方案1. 临时方案修改 _acme-challenge.n9e.op123.ren 的 CNAME 目标为 _acme-challenge.sddts.cn.，等待 TTL 生效后重跑 acme.sh 命令。2. 永久方案A. 配置清单对使用 --challenge-alias sddts.cn 的证书，确保 op123.ren 的 DNS 中存在以下 CNAME（目标均为 _acme-challenge.sddts.cn.）：主机记录（或等效）类型目标_acme-challengeCNAME_acme-challenge.sddts.cn._acme-challenge.ngrokCNAME_acme-challenge.sddts.cn._acme-challenge.toolsCNAME_acme-challenge.sddts.cn._acme-challenge.atzlinuxCNAME_acme-challenge.sddts.cn._acme-challenge.apiCNAME_acme-challenge.sddts.cn._acme-challenge.mcpCNAME_acme-challenge.sddts.cn._acme-challenge.n9eCNAME_acme-challenge.sddts.cn.B. 验证方法签发前可用下列命令确认 CNAME 是否正确：dig _acme-challenge.n9e.op123.ren CNAME +short # 应返回: _acme-challenge.sddts.cn.3. 预防措施新增子域时，同步在 DNS 中为该子域添加 _acme-challenge.<子域> 的 CNAME 记录。使用文档或清单列出所有需 CNAME 的子域，避免漏配或拼写错误。重要变更后使用 dig 或脚本批量校验 CNAME 目标。五、经验总结1. 做得好的地方报错信息明确指向 _acme-challenge.n9e.op123.ren，便于缩小范围。结合 acme.sh 官方 DNS alias 文档可快速理解「每个域名需独立 CNAME」的机制。通过 dig 直接发现 CNAME 目标拼写错误（acmhe vs acme），定位根因。2. 需要改进的地方初次配置多子域 CNAME 时未逐条校验，导致错误在签发时才暴露。可考虑在文档或运维流程中固化 CNAME 清单与校验步骤。3. 流程优化建议将「acme.sh + challenge-alias」所需 CNAME 列表与校验命令写入内部运维文档或 Runbook。证书续期或新增子域后，增加一次 dig 抽查或脚本校验，确保所有 _acme-challenge 的 CNAME 指向正确。六、参考资料acme.sh DNS alias modeacme.sh 官方仓库
黑灰产业运营模式分析一、事件概述1. 事件背景在互联网流量红利见顶的当下，灰产团队展现出惊人的运营能力和市场敏锐度。本文基于对国内黑灰产两大派系的观察，分析其运营模式和方法论，以期从中提取可借鉴的商业智慧。2. 影响范围A. 涉及领域电商平台：好评返现、薅国补内容平台：流量套利、规则漏洞利用社交媒体：减肥祛痘、国学等垂直品类推广B. 参与主体福建帮：重路线黑产集团郑州帮：互联网灰产团队（30 岁以下为主）3. 严重程度灰产运营对正常商业秩序造成冲击，扰乱市场公平竞争，同时也反映出传统企业在敏捷性和执行力方面的不足。二、两大派系对比1. 福建帮：重路线黑产A. 业务模式核心业务：诈骗、赌博运营地点：转移至国外组织规模：大型集团化运作B. 风险特征法律风险：在刑法边缘反复横跳暴利但短命：进去是迟早的事2. 郑州帮：互联网灰产A. 业务模式围绕互联网生态：好评返现、薅国补、A 货追逐热点：减肥祛痘、大小国学，什么火搞什么团队结构：30 岁以下小年轻为主B. 运营特征快进快出：一个项目跑一波数据，赚到就撤绝不恋战：数据不行马上换方向graph TD A[黑灰产业] --> B[福建帮] A --> C[郑州帮] B --> B1[重路线] B1 --> B2[诈骗、赌博] B1 --> B3[办公地点：国外] B1 --> B4[风险：刑法边缘] C --> C1[互联网灰产] C1 --> C2[好评返现] C1 --> C3[薅国补、A货] C1 --> C4[减肥祛痘、国学] C1 --> C5[30岁以下团队] C1 --> C6[快进快出]三、郑州帮运营方法论分析1. 市场嗅觉极其敏锐A. 流量红利捕捉什么品类有流量红利，他们永远先知道什么渠道有规则漏洞，他们第一时间切入B. 信息优势来源每天专注研究平台规则和流量变化大部分做内容的人还在纠结选题时，他们已经开始执行2. 执行力碾压A. 决策到执行发现机会到上手操作：不超过 48 小时没有会议、没有脑暴、没有 PPT直接干，干完看数据B. 迭代速度数据不行马上换这种迭代速度，很多公司一个季度都跑不出来3. 绝不恋战A. 止损心态项目不行就撤不会因为我都投入这么多了就死扛B. 对比创业者沉没成本把人拖死的案例太多这种心态反而是很多创业者最缺的东西sequenceDiagram participant M as 市场 participant Z as 郑州帮团队 participant P as 平台 participant D as 数据分析 M->>Z: 流量红利出现 Z->>Z: 敏锐捕捉机会 Z->>Z: 决策（<48h） Z->>P: 上手操作 P->>D: 返回数据 D->>Z: 数据分析 alt 数据良好 Z->>Z: 持续运营 else 数据不佳 Z->>Z: 立即止损 Z->>M: 寻找下一个机会 end四、方法论迁移与反思1. 同样的能力，不同的路A. 灰产视角市场嗅觉敏锐 → 寻找规则漏洞执行力强 → 快速收割流量绝不恋战 → 逃避监管打击天花板：不被抓B. 正业视角市场嗅觉敏锐 → 发现商业机会执行力强 → 快速验证假设绝不恋战 → 快速迭代产品天花板：印钞机2. 精益创业的实践A. 核心原则快速验证：最小可行产品（MVP）小步快跑：持续迭代优化数据驱动：用数据说话B. 灰产与精益创业的对比维度灰产实践精益创业相似度验证方式跑数据看效果投放 MVP 测反馈⭐⭐⭐⭐⭐迭代周期<48 小时1-2 周⭐⭐⭐⭐决策依据数据说话数据 + 用户访谈⭐⭐⭐⭐止损机制不行就撤失败快速放弃⭐⭐⭐⭐⭐3. 方法论的本质A. 核心观点搞钱这件事，方法论从来不是稀缺的，稀缺的是你把它用在哪条路上。B. 能力模型的价值同样的能力模型用在不同的地方一个是定时炸弹一个是印钞机graph LR A[方法论能力] --> B{应用场景} B --> C[灰产业务] B --> D[正经营业] C --> C1[短期暴利] C --> C2[法律风险] C --> C3[定时炸弹] D --> D1[长期价值] D --> D2[持续增长] D --> D3[印钞机]五、对正规企业的启示1. 敏捷性的缺失A. 决策链条过长会议过多、流程冗长从发现机会到执行往往需要数周甚至数月B. 数据文化薄弱很多决策基于直觉而非数据缺乏快速测试和验证机制2. 沉没成本的陷阱A. 项目死扛现象投入越多越舍不得放弃错失转型和止损的最佳时机B. 对比灰产思维灰产团队的止损文化值得学习失败是学习，不是负担3. 市场敏感度A. 流量红利感知正规企业往往后知后觉缺乏对平台规则变化的持续关注B. 运营策略调整需要建立更灵活的运营机制小团队快速试错，大团队规模化复制六、合规底线1. 边界意识学习灰产的执行力和方法论绝不跨越法律和道德底线2. 长期主义灰产的快钱不可持续正道的钱赚得心安3. 社会责任商业成功不应以破坏市场秩序为代价用正确的方式做正确的事七、总结灰产团队展现出的市场敏锐度、执行力和止损意识，恰恰是很多正规企业所欠缺的。将这套方法论应用于正道，结合合规经营和长期主义，才是商业成功的正确路径。方法本身是中性的，关键在于你选择什么样的道路。参考资料莫森 | 破局哥 on X
Let's Encrypt 发布 DNS-PERSIST-01：基于 DNS 的持久化挑战验证新模型
Let's Encrypt 发布 DNS-PERSIST-01 新挑战类型简化证书自动化一、新闻概述1. 标题Let's Encrypt 发布 DNS-PERSIST-01：基于 DNS 的持久化挑战验证新模型2. 发布时间2026 年 2 月 18 日3. 来源Let's Encrypt 官方博客二、核心内容1. 事件摘要A. 主要内容Let's Encrypt 宣布正在实施支持一种全新的 ACME 挑战类型 DNS-PERSIST-01，该类型基于新的 IETF 草案规范。B. 核心亮点持久化授权记录，一次配置长期有效无需每次续期时更新 DNS 记录将授权直接绑定到 ACME 账户和 CA支持范围控制和可选过期时间特别适合 IoT 部署、多租户平台和批量证书操作场景2. 关键信息A. 版本信息基于 IETF 草案规范：draft-ietf-acme-dns-persist-00B. 重要数据CA/Browser Forum 投票 SC-088v3 于 2025 年 10 月全票通过IETF ACME 工作组于同月采纳该草案预计 2026 年第一季度末在测试环境推出生产环境预计 2026 年第二季度推出C. 涉及技术ACME 协议DNS TXT 记录验证Pebble（Let's Encrypt 的 CA 软件 Boulder 的迷你版本）lego-cli 客户端实现3. 背景介绍A. 传统 DNS-01 挑战DNS-01 挑战是 Let's Encrypt 提供的域名验证方式之一，特别适用于需要通配符证书或不愿将基础设施暴露到公网的用户。其工作原理是客户端在 DNS TXT 记录中发布 Let's Encrypt 生成的令牌，Let's Encrypt 通过查询 DNS 来验证域名控制权。B. 存在的问题传统 DNS-01 挑战虽然广泛支持且经过实战验证，但存在显著的运营成本：DNS 传播延迟导致验证等待时间每次续期都需要更新 DNS 记录自动化流程通常需要在基础设施中分发 DNS 凭据三、详细报道1. 主要内容A. DNS-01 的重复验证机制传统 DNS-01 挑战依赖 Let's Encrypt 生成的一次性令牌。ACME 客户端需要将包含该令牌的 TXT 记录发布到 _acme-challenge.<YOUR_DOMAIN>，Let's Encrypt 查询 DNS 确认值匹配。由于每次授权都需要新令牌，DNS 更新成为签发工作流程的必要环节。优势在于每次成功验证都提供了当前控制域名 DNS 的新证明。但在实践中，这意味着：DNS API 凭据存在于签发管道的某个位置验证尝试涉及等待 DNS 传播DNS 变更频繁发生——大型部署中可能每天多次B. DNS-PERSIST-01 的持久化授权机制DNS-PERSIST-01 采用不同的验证方法。它不是为每次签发发布新的挑战记录，而是发布一个持久的授权 TXT 记录，标识允许为此域名签发证书的 CA 和特定 ACME 账户。对于主机名 example.com，记录位于 _validation-persist.example.com：graph LR subgraph DNS_01["传统 DNS-01 流程"] A1[ACME 客户端] -->|每次签发/续期| B1[更新 _acme-challenge 记录] B1 --> C1[Let's Encrypt 验证] C1 -->|等待 DNS 传播| D1[颁发证书] end subgraph DNS_PERSIST_01["DNS-PERSIST-01 流程"] A2[ACME 客户端] -->|一次性配置| B2[设置 _validation-persist 记录] B2 --> C2[Let's Encrypt 验证] C2 -->|无需等待传播| D2[直接颁发证书] D2 -->|后续续期| D2 end记录格式示例：graph TB A["_validation-persist.example.com. IN TXT"] --> B["letsencrypt.org;"] A --> C["accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"] style A fill:#e1f5ff style B fill:#fff3cd style C fill:#fff3cd一旦该记录存在，就可以用于新的签发和所有后续续期，从操作上将 DNS 变更从关键路径中移除。2. 技术细节A. 安全权衡DNS-01 中的敏感资产是 DNS 写入权限。在许多部署中，DNS API 凭据分布在签发和续期管道中，增加了攻击者可能泄露它们的位置数量。DNS-PERSIST-01 将授权直接绑定到 ACME 账户，允许 DNS 写入权限在初始设置后保持更严格的控制。权衡在于，由于授权记录随时间持续存在，保护 ACME 账户密钥成为核心关注点。B. 范围和生命周期控制DNS-PERSIST-01 引入了显式的作用域控制。默认情况下，授权仅适用于经过验证的完全限定域名（FQDN），并且无限期有效。通配符证书支持添加 policy=wildcard 可将授权范围扩展到经过验证的 FQDNN、通配符证书（如 *.example.com）以及后缀与经过验证的 FQDN 匹配的子域名：graph TB A["_validation-persist.example.com. IN TXT"] --> B["letsencrypt.org;"] A --> C["accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"] A --> D["policy=wildcard"] style A fill:#e1f5ff style B fill:#fff3cd style C fill:#fff3cd style D fill:#d4edda可选过期时间不希望授权无限期持续的订阅者可以包含可选的 persistUntil 时间戳。这限制了记录可用于新验证的时长，但也意味着必须在过期前更新或替换记录。使用此功能的用户应确保有充分的提醒或监控机制，以防止授权意外过期。时间戳表示为自 1970-01-01 以来的 UTC 秒数：graph TB A["_validation-persist.example.com. IN TXT"] --> B["letsencrypt.org;"] A --> C["accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"] A --> D["persistUntil=1767225600"] style A fill:#e1f5ff style B fill:#fff3cd style C fill:#fff3cd style D fill:#f8d7da多 CA 授权可以通过在 _validation-persist.<YOUR_DOMAIN> 发布多个 TXT 记录来同时授权多个 CA，每个记录包含要授权的 CA 的 issuer-domain-name。在验证期间，每个 CA 查询相同的 DNS 标签并仅评估与其自己的 issuer-domain-name 匹配的记录。C. 架构对比graph TB subgraph 传统["传统 DNS-01 验证"] direction TB C1[客户端] -->|获取令牌| C2[更新 DNS TXT 记录] C2 -->|等待传播| C3[Let's Encrypt 验证] C3 -->|颁发证书| C4[证书签发] C4 -->|90天后| C5[需要续期] C5 --> C2 end subgraph 新方案["DNS-PERSIST-01 验证"] direction TB P1[客户端] -->|一次性| P2[设置持久授权记录] P2 --> P3[Let's Encrypt 验证] P3 -->|颁发证书| P4[证书签发] P4 -->|90天后| P5[需要续期] P5 -->|无需 DNS 更新| P3 end style 传统 fill:#fff3cd style 新方案 fill:#d4edda3. 数据与事实A. 规范进展CA/Browser Forum 投票 SC-088v3 定义 3.2.2.4.22 DNS TXT Record with Persistent Value DCV 方法2025 年 10 月全票通过IETF ACME 工作组同月采纳草案B. 实现支持Pebble（Boulder 的迷你版本）现已支持lego-cli 客户端实现正在开发中四、影响分析1. 行业影响A. 技术趋势从临时验证转向持久授权模式减少对 DNS API 的依赖，降低凭据泄露风险优化自动化证书管理流程B. 标准化进展IETF 草案虽然仍处于活跃状态，但描述的核心机制预计不会有实质性变化。2. 用户影响A. 现有用户可继续使用传统 DNS-01 挑战迁移到 DNS-PERSIST-01 可简化操作流程B. 潜在用户特别适合以下场景：IoT 设备部署（DNS 操作困难）多租户平台（统一授权管理）批量证书操作（减少 DNS 更新次数）C. 迁移考虑需要一次性设置 DNS 记录ACME 账户密钥安全变得更重要建议等待生产环境正式推出后再迁移关键业务3. 技术趋势A. 证书管理演进从频繁操作转向一次性配置关注点从 DNS 操作转向账户安全B. 生态影响其他 CA 可能采纳类似机制ACME 客户端需要更新支持五、各方反应暂未收集到具体的社区反馈和评价。六、相关链接1. 官方公告Let's Encrypt 博客原文IETF 草案：draft-ietf-acme-dns-persist-002. 相关规范CA/Browser Forum 投票 SC-088v3ACME 挑战类型文档3. 技术资源Pebble 项目lego-cli 客户端参考资料DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt
WiFi 可能成为隐形大规模监控系统研究警告
WiFi 可能成为隐形大规模监控系统研究警告一、新闻概述1. 标题研究人员警告：WiFi 可能成为隐形大规模监控系统2. 发布时间2026 年 2 月 4 日3. 来源SciTechDaily二、核心内容1. 事件摘要A. 主要内容德国卡尔斯鲁厄理工学院（KIT）研究人员发现，利用普通 WiFi 信号可以识别个人身份，即使目标没有携带任何 WiFi 设备。B. 核心亮点无需目标携带任何电子设备即可被识别不需要专用硬件，使用普通 WiFi 设备即可实现识别准确率接近 100%引发严重的隐私担忧2. 关键信息A. 研究机构卡尔斯鲁厄理工学院（KIT）信息安全与可靠性研究所（KASTEL）B. 研究成果论文标题：BFId：利用波束成形反馈信息的身份推断攻击发表于：2025 年 ACM SIGSAC 计算机与通信安全会议（CCS '25）参与者：197 名志愿者准确率：接近 100%C. 涉及技术WiFi 信号分析波束成形反馈信息（BFI）IEEE 802.11bf 标准3. 背景介绍A. 技术原理该技术通过观察无线电波的传播来创建周围环境和人员图像，其工作原理类似于普通摄像头，但使用的是无线电波而非光波。B. 现有监控手段情报机构或网络犯罪分子目前使用的监控方式包括 CCTV 系统、视频门铃等传统摄像头设备。三、详细报道1. 主要内容A. 技术原理WiFi 信号在空间中传播并与人体相互作用时会产生独特的模式，这些模式可以被捕获和分析。与使用光的摄像头不同，这种技术使用无线电信号来创建类似图像的可识别模式。B. 工作机制该技术利用网络中已连接设备与路由器之间的正常网络通信。这些设备会定期在网络内发送反馈信号，称为波束成形反馈信息（BFI）。这些信息以未加密方式传输，范围内任何人都可以读取。C. 实现方式无需目标携带任何电子设备利用周围其他活跃的 WiFi 设备使用标准 WiFi 设备即可实现不依赖 LIDAR 传感器或信道状态信息（CSI）等专用设备D. 识别流程一旦机器学习模型经过训练，识别过程只需几秒钟。研究人员可以从多个视角生成人员图像，从而实现个体识别。2. 技术细节A. 系统架构graph TB A[WiFi 路由器] -->|无线电波| B[人员移动] B -->|反射信号| C[WiFi 设备] C -->|BFI 数据| D[数据收集器] D -->|分析| E[机器学习模型] E -->|识别结果| F[身份推断]B. 攻击流程sequenceDiagram participant V as 受害者 participant R as WiFi 路由器 participant D as 连接设备 participant A as 攻击者 participant M as ML 模型 V->>R: 移动经过 WiFi 覆盖区 R->>D: 发送波束成形信号 D->>R: 返回 BFI 数据（未加密） A->>R: 捕获 BFI 数据 A->>M: 输入信号模式 M->>A: 返回身份识别结果C. 技术特点被动记录：不需要主动发射信号隐蔽性强：攻击行为不易被发现普适性高：WiFi 网络无处不在3. 数据与事实A. 实验数据参与人数：197 人识别准确率：接近 100%识别时间：几秒钟识别独立性：不受视角或步态影响B. 应用场景经过有 WiFi 网络的咖啡馆办公楼、住宅区任何有活跃 WiFi 设备的场所四、影响分析1. 行业影响A. 隐私保护该技术将每个路由器变成潜在的监控手段，对个人隐私构成严重威胁。B. 标准制定研究人员呼吁在即将推出的 IEEE 802.11bf WiFi 标准中加强隐私保护措施。2. 用户影响A. 隐私风险关闭个人设备无法提供保护只要周围有其他 WiFi 设备活跃即可被识别可能被公共当局或公司用于追踪B. 防护难度普通用户无法检测自己是否被监控现有防护措施难以应对此类攻击3. 技术趋势A. 技术演进无处不在的无线网络可能成为近乎全面的监控基础设施，具有一个令人担忧的特性：它们是隐形且不会引起怀疑的。B. 滥用风险在威权国家，这项技术可能被用于监视抗议者。研究人员特别强调这对基本权利尤其是隐私权构成的风险。五、各方反应1. 研究人员观点A. Professor Thorsten Strufe通过观察无线电波的传播，我们可以创建周围环境和在场人员的图像。这与普通摄像头的工作原理类似，只是我们使用无线电波而不是光波进行识别。因此，你是否随身携带 WiFi 设备并不重要。B. Julian Todt这项技术将每个路由器变成潜在的监控手段。如果你经常经过一家运营 WiFi 网络的咖啡馆，你可能会在不知情的情况下在那里被识别，随后被公共当局或公司识别出来。C. Felix Morsbach无处不在的无线网络可能成为近乎全面的监控基础设施，具有一个令人担忧的特性：它们是隐形且不会引起怀疑的。2. 安全建议加强 IEEE 802.11bf 标准中的隐私保护措施对 BFI 数据实施加密保护提高公众对此类隐私风险的认识六、相关链接1. 论文信息论文标题：BFId：利用波束成形反馈信息的身份推断攻击发表会议：ACM SIGSAC 计算机与通信安全会议（CCS '25）DOI：10.1145/3719027.37650622. 研究机构卡尔斯鲁厄理工学院（KIT）信息安全与可靠性研究所（KASTEL）参考资料Researchers Warn: WiFi Could Become an Invisible Mass Surveillance System