102网管——接入终端中的客户端

本篇文章讲述了实际研发iceHorizonCloud的一些想法。

老规矩~

图0

接下来进入正题~

前言

这个客户端是干啥用的

上节已经说过,这个客户端是针对设备跨三层路由时进行策略随行而准备的,原文章链接:点击这里。同时还可以对接入设备进行安全检查,以避免不正当软件造成的不良影响

我可以在哪里得到这个客户端

经过博主我一番考虑之后,我决定把iHCSC这个客户端开源了。该客户端由Golang编写,借以来实现跨平台。由于是Golang的初学者,再加上经验不是很足,因此代码的规范性可能非常差,还请朋友们包涵,如有建议可以电子邮件我,相关联系方式可以通过博客的“关于我”找到。

仓库地址: https://github.com/ic0xgkk/iHC-SmartClient

功能列表

  • 设备安全检查:目前只实现了进程检查,Windows客户端会强制要求管理员方式启动,进而读取系统中所有的进程名,并拼接成一个长字符串发送到服务端进行匹配。
  • 读取IP和MAC地址:读取方式仍然是使用socket套接字,创建套接字后获取套接字中的源IP,再使用套接字中的源IP地址遍历匹配设备接口查找对应的物理接口,读取相应的MAC地址。
  • 硬件信息读取:包含CPU型号,必要时可以做硬件绑定。
  • 系统信息读取:读取系统类型和版本号,以及主机名等,Windows可以额外读取系统的ID,用于硬件+IP+MAC+系统唯一绑定(服务端还没写)。

实现原理

客户端的实现比较简单,进程获取方式都是使用开源轮子,通信这块使用的HTTPS协议,解析方式为JSON。相关的私有协议还在设计中,还是要话一些时间做私有协议。

服务端设计其实比较简单,没客户端这么复杂。服务端设计是整套的iptables+ipset,IP列表可以使用Linux的动态链接库libipset,golang服务端可以嵌入C语言使用gccgo编译,进而引入动态链接,然后联动后端和防火墙。

服务端还需要嵌套一层nginx做反向代理和负载均衡,以避免接口短时请求压力过高,同时需要打开SSL功能,实际部署时我把HSTS打开了。客户端也会强制要求验证证书,否则不会进行下一步操作。

还在计划的功能

  • 远程诊断:我看H3C iNode缺少一个很必要的功能——远程诊断服务。有时候客户端这边一些莫名其妙的问题,无法判断问题的时候,可能需要使用诊断服务,如果无法连接服务器就可能没什么用处了。
  • 日志收集服务:还在考虑要不要把所有的日志集中进行上传,用于诊断服务和网管使用。当然,这些数据均不会包含用户数据,不过关于进程检查的还是需要在TOS上强调。
  • 管理中心:由于这个系统太过于庞大,因此还是得慢慢考虑和编写,短期要先把专利拿下。
  • 私有协议:要想确保安全,底层的通讯协议和部分加密方式还是需要自己设计,同时代码要做好混淆等防逆向工作。私有协议目前还停留在文档阶段,还没有开始施工,主要是存在不定长字段,加上协议使用UDP传输,不像TCP的流式传输一样可以解决重传和长数据问题。UDP数据要控制长度,否则IP层分片容易出现丢失和乱序。正是因为客户端需要发送进程列表,因此这个字段是不定长同时甚至可能是超长,尽管我们建议局域网尽可能使用巨型帧,但是不排除仍然可能会超出长度。以防万一还是需要在协议上做功夫,因此还需要一段时间。
  • 用户登录:这个是必备功能了,后边肯定要加的,等不同平台客户端问题解决了就可以了。
  • CA安装:这个功能还在考虑做不做,因为一边是隐私问题,一边是国家要求的审计问题。两者相互冲突,用户层面讲需要考虑隐私问题,审计层面讲需要进行完全审计。众所周知,行为审计系统无法应对SSL/TLS加密的内容,但是如果有相应的根证书即可解密,但是这种根证书一般是存在于管理机构,因此审计需要也很难拿到。除了这个办法,还有一种办法是在用户端安装CA证书,可以通过管理员执行的客户端来给客户端证书库安装根证书。
  • TAP/TUN隧道:众所周知,IPv4存在广播,因此二层没有做好防护的情况下,可能会存在广播泛洪,影响性能。比较合适的方法是IPv6,IPv6中取消了广播功能,因此安全层面来讲不容易出现IPv4这样的情况。但是在管理角度来讲,由于IPv6可以通过邻间通告自动配置地址,并不方便管理。对此,我们想到了一种先配置,再认证的方式,即客户端使用v6相互通告完成地址和路由配置,使用v6连接到TAP服务器,流量通过单栈v6的TAP隧道传输,客户端TAP接口上配置IPv4地址和v6地址即可,通过客户端下发路由表即可实现相应功能。这样以来,即可解决大多的管理和用户端配置的问题

额外考虑

  • 性能问题:上边提到,我们把进程检查任务放到了服务端,尽管在字符匹配上做了相应的优化,但是客户端多的时候服务器压力还是挺高的,因为每次心跳里的进程列表也都需检查,对此正在考虑检查工作要不要下放到客户端。

其他

上述的一些想法是已经在实施中的了,也有的还在规划阶段。是目前博主总结网络管理里得出的一些问题,结合自己的研发经验想到的业务逻辑。相关内容已经在进行专利申报。