Skip to content

Latest commit

 

History

History
181 lines (122 loc) · 11.7 KB

transwiser.md

File metadata and controls

181 lines (122 loc) · 11.7 KB

Transwiser 交易所网络架构及安全指引

设计原则

没有绝对的安全,评估风险,控制可能的损失 安全性的提高是以成本提高和便利性降低为代价的,安全成本的投入应随着业务的发展按提高(勿过度安全) 设定的安全准则应严格遵守 架构图

Architecture

遵循循序渐进的原则,初始时采用简化的架构,如下图所示。

Architecture Simplified

架构中主要将拓布分成以下几层

风险区 隔离区 离线区 风险区

API Server 是唯一暴露公网IP的服务器节点,也是直接面向终端用户的节点。可能的攻击最容易针对该节点。因此,该节点将不予其他节点直接连接,包括热钱包和区块链数据服务器。该节点的服务主要包括获取用户请求存/取款地址,返回相关服务参数,如服务可用性(有时可能暂时中止某个币种的充值或体现服务)、服务费率等信息。该服务器通过读取数据库获取相应数据。

为了实现不直接接触钱包服务器,并能满足用户请求充值地址的要求,将在钱包服务器中预先生成地址池,并录入数据库中,每次用户请求新的充值地址时,API Server将从数据库中该币种的地址池中随机提取未分配地址给用户,关联到用户的BitShares用户名,并返回相应数据给用户。

用户提现时,实际上不通过API服务器,在UI中构建向trans-withdraw发送代币资产的交易,其中包含用户收款地址的memo信息。由管理节点收到该交易后处理。API 服务器实际上不参与该环节,不过当然可以保存用户的收款地址,用户下次提现时,显示上次提现地址,已提高用户体验。

隔离区

隔离区中,重点需要保护管理服务器,理想状态下,该服务器无法从公网访问,管理员通过VPN接入。但在初期没有VPN的环境下,可使其直连公网,但其域名或者IP地址应处于保密状态,不对外公开。对外部的www和ssh端口的链接限制来源IP,以确保仅来自特定IP的用户可以进行连接和访问服务www和ssh服务。

区块链数据服务器和热钱包服务器不可避免的需要直连公网,同样需要对服务器的开放端口进行限制,并且钱包的RPC服务端口应只对内网开放,只针对管理服务器开放。分级的热钱包确保每一级热钱包的余额不能超过设定上限,已使在热钱包服务器被攻破后的损失可控。

离线区

冷钱包 冷钱包中存储大数量的数字资产,如果资产数量较大,可分成多个冷钱包地址进行存储。冷钱包的要求是必须存放在离线的电脑中,需要从冷钱包地址中提取资金时,对交易进行离线签名,通过U盘将已签名交易转移至联网工作电脑后进行广播。

暖钱包 使用冷钱包会较大降低便利性和工作效率,暖钱包只在本地专用个人电脑中存在,电脑处于联网状态,其中存有较大额度的资产。使用时比较便利,但是面临个人电脑病毒的威胁。务必使用强密码加密钱包,仅在需要时解开。

钱包管理

分层级热钱包 热钱包分级制,从1级至n级,不同级热钱包不允许存在同一台服务器上。每一级热钱包根据币种不同设定额度上限,即该热钱包中的余额不允许超过额度,如果超过,监察程序将超额部分转移至上级热钱包,如果上级钱包余额溢出,则再向上转移,直至冷钱包。

1级热钱包中包含n个用户的充值地址,1个热钱包地址 上级热钱包中不包含用户充值地址,只包括1个热钱包地址 热钱包应该平时处于锁定状态,密码不存在本服务器上。在需要支配金额时,由管理节点的管理程序进行解锁并执行相应操作。

用户的充值地址 这里所说的充值是指用户通过充值BTC, ETHER等他链代币,已获得BitShares系统中Trans.XXX代币的过程中的他链地址,这些地址每个用户不同,同一个用户就同一个他链资产可以拥有多个充值地址,但只有一个是当前充值地址。这些地址在Transwiser的1级热钱包中存在,并由Transwiser控制。

为避免API服务器在用户请求充值地址时,直接与热钱包沟通生成新的充值地址。将事先批量生成地址,并将地址信息存储在数据库中共API服务器使用和标记。这些批量生成的地址将导入到1级热钱包中,当充值地址库存数量不足时,由监察程序补充生成新地址,导入1级热钱包并记录到数据库中。

用户的提现地址 热钱包中不含用户的提现地址,用户在请求提现时,通过发送Trans.XXX代币到1级热钱包地址,并通过memo附带他链代币接受地址来完成。

钱包的余额 热钱包主要用于支付,包括用户的提现请求,和用户充值后发送的UIA资产。实际上,绝大部分的支付将有1级热钱包发送。只有当要求支付的金额超过1级钱包的最高额度时,支付请求将由上级第k级热钱包(额度足够满足的情况下)完成,直至请求额度超过最上级热钱包时,该请求作为pending状态,请求人工处理。人工处理的方式将从冷钱包补充额度至最高层热钱包,并通过热钱包发送。

但在初期,建议如果要求支付的金额超过1级热钱包额度时,即进入人工审核过程,由人工确定是否支付。如果同意支付的话,则应用上述流程。

余额调度 每一级热钱包中的余额不能超过设定额度是铁律,由监察程序负责检查和进行资金转移。资金的转移是双向的,极可能从低级热钱包流向高级热钱包,也可能从高级热钱包流向低级热钱包。具体情况如下:

当用户完成充值后,检查程序将从用户的充值地址中提取全部余额转移到1级热钱包地址中,所以该地址中的余额会不断增加,直到溢出(超过该级钱包允许的额度)时,监察程序将溢出部分转移至上级热钱包。这时,他链资金的流向是从低级钱包流向高级钱包的。而BitShares的1级钱包地址将向用户的BitShares用户名发送相应的IOU资产,这时BitShares的1级钱包中的资产将减少,如果余额少于设定阈值,比如额度的20%时,则监察程序将从BitShares的上级热钱包转移资金至1级钱包已补足额度。

当用户提现时,即发送BitShares网络中Trans.xxx等IOU资产到BitShares的1级钱包地址,并附带他链接受地址时,IOU进入1级钱包地址,如果溢出,则会被转移到上级热钱包。等待BitShares IOU成熟后,监察程序将从他链热钱包中发送相应提现金额到用户他链地址。

提现额度 为降低风险,可对用户的提现额度和频次进行限定。一般通行的做法是根据用户认证级别以及交易活跃等级分成不同每日可提现额度。在BitShares网络中,除非进行额外的身份实名认证,否则用户将是不可是别的,初期没有额外认证的前提下,可一视同仁设定每日提现额度,如果超过额度,或者延迟到下一周期处理,或者提交人工审核后处理。以后或可根据用户交易Trans资产的交易量分级,越活跃的用户获得的提现额度和频次可更高些。

当然也不排除将来完全自定义界面,正式建立交易所,为符合监管要求而引入实名制。

管理节点

管理节点是整个系统的引擎和核心,所有的日常工作由管理引擎自动完成,随着系统的成熟,将提高运作的自动化程度,降低人工审核和干预的程度。管理节点实际上也应从职能和权限上分开部署到不同的服务器上,比如热钱包管理调度程序拥有热钱包的私钥,它能够自动执行管理任务,权限很大,可独立与一台服务器。而提供管理界面的服务器因与内部不同权限的工作人员接触,可只保存私钥片段,操作人员执行特定任务时需要提供额外片段才能完成任务。

但在初期可整合在一起降低系统复杂度。

管理节点需要承担的任务主要包括以下:

操作人员权限分配和认证 和通常的管理系统类似,不同的操作人员通过登录账号分配有不同的权限,所有的操作日志均进行记录和保存。

运营状态 系统运营的方方面面状态的迅速反馈。

地址池检查 用户充值地址池的监察,不足时补充。

热钱包余额检查 监察各级热钱包余额,溢出时将多余部分转移至上级热钱包,直至冷钱包;低于库存余额阈值时,将从上级热钱包转移资产以补足到余额水平的80%(不补足100%的原因是防止完全补足后,用户进行冲提现操作,造成立刻回转)。

用户充值处理 当用户发送他链代币比如BTC到他的充值地址时,充值监察程序将在等待到该资产成熟时(比如比特币需要等待6个块确认也可更少,或者根据充值额度动态实时调整),确认用户已完成充值,将金额从用户充值地址转移到1级钱包发送地址,并发送相应数量的Trans.BTC代币到用户的BitShares账户中,完成整个过程。

用户充提现处理 监控用户充值地址及热钱包地址,用户发生冲提现交易时,进行合法性校验,包括用户操作额度频次检查,可疑行为检查(细节待定),操作余额检查等动作。一切正常时自动执行,发生任何问题是,拒绝执行,并标记待审核,由人工决定处理方式。

服务控制 包括暂停币种的冲提现服务,设定分级热钱包额度等参数。

安全风险及评估

API Server 被攻破 黑客无法从物理上链接到管理节点或者是钱包节点,无法造成损失。但是可能获得数据库的控制权,从而修改用户充值地址到其自行控制的地址,以获取用户新的数字充值款。但一般用户在充值后,尤其是数字资产充值后没有看到余额的提现会很快联系客服,所以在黑客完成攻击直到Transwiser收到第一个用户投诉到调查完毕期间的用户充值额度为可能的损失。

管理网站账户泄露

一般工作人员/客服倒戈

Alex工作电脑被黑客控制

Alex倒戈

巨蟹工作电脑被黑客控制

巨蟹倒戈

Specs

最低硬件要求,按业务发展弹性扩展。

API Server

2 Core, 2G Mem, 20G HD to start Port: 80, 2222(ssh) (deny all other) Limited Access to RDS instance / tables Fail2Ban + UFW firewall RDS Instance:

2G Mem, 5G HD to start MySql Server intranet access only Management Server

4 Core, 4G Mem, 100G HD to start Port: 80, 2222(ssh) (deny all other) Access IP whitelist Fail2Ban + UFW firewall Blockchain + Wallet (Ubuntu)

4 Core, 8G Mem, 500G HD to start (BitShares, Ethereum, Bitcoin node+wallet) Port: Blockchain required ports to public Port: 2222(ssh) allow from intranet only Wallet provided RPC ports: allow from intranet only Fail2Ban + UFW firewall Blockchain + Wallet (AntShares, windows server)

2 Core, 2G Mem, 80G HD to start AntShares Port: Blockchain required ports to public Remote Desktop: allow access from intranet only (need to confirm) Wallet provided RPC ports: allow from intranet only Windows Based Firewall (need to confirm) 系统参数初始设置建议

热钱包额度及库存阈值

链 资产名 热钱包级别 额度 库存阈值 BitShares Trans.BTC L1 30 6 BitShares Trans.DAO L1 100,000 6 BitShares Trans.AntShare L1 TBC 6 Bitcoin BTC L1 30 6 Ethereum DAO L1 100,000 6 AntShares AntShare L1 TBC 6 BitShares Trans.BTC L2 90 6 BitShares Trans.DAO L2 300,000 6 BitShares Trans.AntShare L2 TBC 6 Bitcoin BTC L2 90 6 Ethereum DAO L2 300,000 6 AntShares AntShare L2 TBC 6 服务可用性

资产 充值 提现 提现额度(每日) Trans.BTC YES YES 6 Trans.DAO YES YES 20,000 Trans.AntShare YES YES TBC