EOS核心安全架构设计
发布于 4 个月前 作者 stvenyin 30945 次浏览 来自 EOS
    1. EOS RAM公式破解
    1. EOS DDOS防护
    1. 目录
    1. 架构核心目标
    1. 面临的主要问题
    1. 架构核心设计
    1. 核心防御
    1. 推荐总架构
    1. 其它架构
      1. 单链路方案
      1. 多负载方案
      1. 入门级方案
    1. 安全加固方案
      1. RPC/API 安全
    1. 1.1 屏蔽 RPC/API
    1. 1.2 RPC/API 防护
      1. 命令安全
    1. 2.1 密码安全
    1. 2.2 开启日志记录
    1. 2.3 设置最低交易价格
    1. 2.4 并发连接数优化
    1. 2.5 非 root 启动 ontology
      1. 网络安全
    1. 3.1 网络架构
    1. 3.2 云服务商
    1. 3.3 DDoS 防御
      1. 主机安全
      1. 威胁情报
      1. NormalNode(普通节点)核心安全配置总结
    1. 致谢
    1. 架构核心目标
    1. 保护出块服务器正常通信与运行
    1. 增强初始主网整体抗攻击能力
    1. 保护节点安全
    1. 面临的主要问题
    1. 对初始状态主网进行 DDoS
    1. RPC/API 功能被未授权访问及滥用
    1. 通信故障
    1. 架构核心设计
    1. TSN 服务器隔离
    1. 多跳转节点(小节点流量转发,大节点高防护)
    1. 多链路高可用
    1. 对比 EOS 架构,适当降低单节点成本,增加整体数量,并保证 TSN 的稳定
    1. 核心防御
    1. 默认关闭 RPC/API 。必须打开时,混淆端口,并架设高防等保护
    1. TSN 通信多链路设计
    1. TSN 服务器不在公网上暴露,通过跳板服务器(跳板服务器数量要大)进行通信
    1. 在外网公布的跳板服务器遭遇持续性攻击时通过备用链路进行通信
    1. 防止全网扫描定位高防后的服务器,修改同步端口 20338 (同理 RPC/API 的 20334-20337 )至全网最大存活数量的端口 80、443 或 22,这样可以有效抬高攻击者定位成本。
  • 推荐总架构
  • arch.png
  • 架构说明:
  • 为了应对可能的 DDoS 攻击,节点应准备多条链路,在攻击到来后,可以随时通过备用链路进行通信,确保主网顺利启动,并持续出块。
  • 在没有攻击情况下,外围节点通过对外公布的公开节点进行通信。
  • 其它架构
  • 随着主网 TSN 节点的增多,整体的抗攻击能力增强,新增节点在考虑节省成本的情况下可适当降配
    1. 单链路方案
  • arch-p1.png
    1. 多负载方案
  • arch-p2.png
    1. 入门级方案
  • arch-p3.png
  • 安全加固方案
    1. RPC/API 安全
  • 1.1 屏蔽 RPC/API
  • 如无必要,建议禁止 RPC/API 对外访问。
  • 1.2 RPC/API 防护
  • 不建议把节点的 RPC/API 端口直接暴露在公网中,如有暴露的需求请在端口之前添加保护措施
  • 查询用 RPC/API 所在 full node 与 TSN 完全隔离并架设防御,保证外网对 RPC/API 的攻击不能影响到 TSN。
    1. 命令执行安全
  • 命令详细使用说明可参考官方手册 Ontology CLI User Guide
  • 2.1 密码安全
  • –password, -p
  • password 参数用于指定 Ontology 节点启动的账户密码。因为在命令行中输入的账户密码会被保存在系统的日志中,容易造成密码泄露,因此在生产环境中建议不要使用该参数。
  • 2.2 开启日志记录
  • –loglevel
  • loglevel 参数用于设置 Ontology 输出的日志级别。默认值是1,即只输出 info 级及其之上级别的日志,建设使用默认配置。
  • 2.3 设置最低交易价格
  • –gasprice
  • gasprice 参数用于设定当前节点交易池接受交易的最低 gasprice ,默认为0,建议设置一个大于零的值以防止交易阻塞攻击。
  • 2.4 并发连接数优化
  • P2P 端口并发连接数为无限制,可优化ulimit系统参数和内核参数,增强恶意连接攻击承受能力。
  • 2.5 非 root 启动 ontology
  • 建议编译完成后,创建普通用户账号,并使用该账号启动 ./ontology,避免使用 root,降低风险。
  • 2.6 监听随机端口
  • –nodeport=PORT1
  • –rpcport=PORT2
  • 建议设置为非默认端口,如果是对外服务的,建议采用 主机安全中的配置方法
    1. 网络安全
  • 3.1 网络架构
  • 为应对可能的 DDoS 攻击导致节点主网络阻塞的问题,建议提前配置备份网络,例如私密 VPN 网络。
  • 3.2 云服务商
  • 经慢雾安全团队测试,Google Cloud、AWS 及 UCloud 等具有更好的抗 DDoS 攻击的性能,并且在 DDoS 攻击过后服务商不会临时封锁服务器,可以极为快速的恢复网络访问,推荐北斗共识集群使用。(请谨慎选择云服务商,许多云服务商在遭遇 DDoS 等攻击时会直接关闭服务器)
  • 3.3 DDoS 防御
  • 为应对可能发生的 DDoS 攻击,建议北斗共识集群提前配置 Cloudflare、AWS Shield 等 DDoS 高防服务。
    1. 主机安全
  • 防止全网扫描定位高防后的服务器,修改同步端口 20338 (同理 RPC/API 的 20334/20335/20336)至全网最大存活数量的端口 80、443 或 22,这样可以有效抬高攻击者定位成本。
  • 关闭不相关的其他服务端口,并在 AWS 或 Google Cloud 上定制严格的安全规则。
  • 更改 SSH 默认的 22 端口,配置 SSH 只允许用 key (并对 key 加密)登录,禁止密码登录,并限制访问 SSH 端口的 IP 只能为我方运维 IP。
  • 在预算充足的情况下,推荐部署优秀的 HIDS(或者强烈建议参考开源的 OSSEC 相关做法),及时应对服务器被入侵。
    1. 威胁情报
  • 强烈建议做好相关重要日志的采集、储存与分析工作,这些日志包括:RPC/API 与 P2P 端口的完整通信日志、主机的系统日志、节点相关程序的运行日志等。储存与分析工作可以选择自建类似 ELK(ElasticSearch, Logstash, Kibana) 这样的开源方案,也可以购买优秀的商业平台。
  • 如果使用了成熟的云服务商,他们的控制台有不少威胁情报相关模块可重点参考,以及时发现异常。
  • 当节点出现重大漏洞或相关攻击情报,第一时间启动应急预案,包括灾备策略与升级策略。
  • 社区情报互通有无。
    1. 核心安全配置总结
  • 选用 Google Cloud、AWS 及 UCloud 等可靠的云服务商做节点基础设施,服务器配置在双核4G以上
  • 配置规则禁止与 node 服务不相关的其他服务端口开放( SSH 只开启证书登陆并限制访问 SSH 端口的 IP 只能为我方运维 IP )
  • 使用非 root 运行 node 程序,启动时随机指定P2P端口,并且若无必要则不开启 RPC/API
  • 致谢
  • 在此非常感谢
  • Ontology Team
  • 大力支持节点安全测试,为社区安全积累了宝贵的数据。
  • 奉献精神比较重要耶
  • Thank you very much.
回到顶部