未经作者许可禁止转载
本文地址：https://jxcn.org/2022/03/qnap-security/

最后更新日期：2022年4月2日 18点33分

作为本系列的最后一篇文章，其实也是想随意讲讲QutsCloud这个产品，说说我心里对它的真实评价，无论褒贬，不仅限于安全性。

1. 回顾

首先回顾一下这半个月的经历吧

  • 2022年3月13日，在qnap官网下载了vmdk镜像，在esxi上进行安装
  • 2022年3月16日，购买了一个月的授权，正式开始逆向之旅
  • 2022年3月21日，基本已完成了qlicense 以及签名校验实现的逆向
  • 2022年3月22日，搭建了基于hugo的blog准备写下这一系列的文章
  • 2022年3月24日，写下第一篇文章
  • 2022年3月28日，完成此系列大部分内容（除自建qlicense服务器及syslinux安装）

这半个月基本上我也没有过多使用qutscloud网页上的功能，主要在读脚本，逆向库文件，看strace跟踪，以及用gdb调试，使用比较频繁的工具有

也用到python写一些脚本来分析库文件

2. 评价

Qutscloud是基于云的NAS主机系统，官方的介绍中，大部分场景还是配合基于硬件的QTS来同步或者传输文件，但是功能与QTS并没有差异太多，存储池，卷，快照，硬件QTS支持的它都支持。QTS支持的客户端软件它也一个不落。

按照现在的价格4.99美金一个月，可以说贵，但是也并没有贵太多。如果只有两个或者4个盘，这个价格确实比不上硬件的QTS，可QutsCloud是支持24块硬盘（不含启动盘），而且是不需要许可买的，许可只限制cpu的数量。想想八盘位的NAS价格，只要硬盘数量一多，价格优势一下子就出来了，更别说像群晖已经在限制硬件NAS可用的硬盘品牌了，只接受它认证过的硬盘，这不是赤裸裸的收割吗。

对于NAS的主职，存储文件，以及保证数据安全，QNAP是有一套自己的原则的，4盘位及以下的机器，使用QTS，八盘位以上的既可以使用QTS也可以使用QutsHero，而QTS可以作为虚拟机运行在QutsHero之上，由此可见，QNAP是想把QTS做成主职应用，兼职存储的系统，而基于zfs的QutsHero则专职存储，QutsCloud则是云上的应用，这样各有侧重，能够满足市场不同的需求。

在vQTS推出前我其实就想有没有一个功能像现在NAS一样，可以同步照片，可以分享文件的系统放在云端运行，在vQTS推出后我也做了在虚拟机上安装的尝试，不过要上云还是有点困难，至少要多加一块硬盘。

现在的欠缺是官方的应用太少了，给用户自己打包的工具看起来也不是很好用，大部分时候想用软件的时候只能用docker。

3. 安全

  • 作为一个云上的系统，居然没有防火墙？？(有防火墙APP，但是显然这个应该内置吧)
  • 安装app后，有很多app还是通过其他的端口访问，本地访问没关系，通过域名访问的话证书怎么做，正常应该提供一个基于域名或者路径的反代吧？（现在支持virtual web host，但是端口转发依然很麻烦）
  • 几乎没有审计功能，没有任何一个界面能找到哪个用户，哪个ip访问了哪个url，或者访问了什么功能，所以为什么QTS每次都后知后觉，等被入侵了不知道多少台才匆匆升级系统打补丁。（这个比较重要）
  • 用户分级粒度太大了，看起来只是做了基于url的分级访问，反正新建的用户我不敢给陌生人用 （设计缺陷，尤其是没有给app一个良好设计的权限系统）
  • 对系统文件签名感觉没什么用，启动之后固件就躺在那里，验证签名有啥用，NAS启动了没什么问题都不会关机的，如果有恶意程序修改了系统内的文件，光检查固件也是检查不出来的，不如对系统的可执行文件做个哈希的列表，隔一段时间检查是不是多了文件或者是少了文件，或者文件发生了变化，对固件签名不如对文件的哈希列表签名。（完整性检查对系统来说是必须的）
  • 对应用包的签名也是一样，QPKG的签名没有包含文件长度，QDK验证签名甚至可能直接执行恶意代码（QNAP应用的签名就是在瞎搞）

4. 建议

QutsCloud是上云的系统，不应该设计的和QTS一样，一旦被入侵，数据几乎没有挽回的机会了。功能最小化，权限隔离这样最基础的要应该做，不说像QutsHero把数据存储和应用用虚拟化分隔开，起码访问审计要做好吧。

下面是我的两个比较容易实现的小建议：

  1. 为不同的应用提供一个共同的鉴权入口，不同的应用有不同的端口，如果有鉴权的话有可能也有另外一套自己的用户系统。这样就提供了一个最小权限。

    可以这样，为session添加一个cookie作为token，所有的app页面都要求cookie鉴权才能访问，并且是在web server中检查。检查通过才运行访问，这样只要反代所有的应用端口就实现了单一入口的鉴权，做OAuth当然也可以，但是在鉴权之前访问任何其他页面都不安全，甚至可以说，除了登录页面，其他任何页面都是不安全的。

  2. 匿名访问的url要在单独的容器中运行，同时限制用户可以提交以及访问的内容。比如有一个url，既可以是登录用户访问，也可以是匿名用户访问，如果是匿名访问，则将匿名用户的访问代理到容器中，对系统的更改则作为一个更小的集合由系统提供。

5. 最后

虽然写了这一些列文章，但是我应该还是会买个正版再继续用一段时间，一年50美金，个人感觉不算过分。

另外，部分TBD的文章也许会更新，也许不会，至少本周之内不会更新。

6. 数据安全

总结：请尽量使用静态卷

老实说我也没想到，什么都还没存呢，就raid损毁，用的是默认的厚卷，看了一下也不知道怎么修复，直接删了重建算了，这玩意就很不靠谱，license一旦失效就要改成只读，但是内核驱动似乎有点问题，会卡死，用license server感觉还不如给cmd打补丁了，起码不会受license回调的影响，特么的每次license变化都会去调用storage_util一次来修改文件系统挂载状态为只读，这能不出事么。

假如客户要换一台机器激活然后转移数据，原来的机器app停了也就罢了，留个filestation啥的传输数据不就得了么，偏要折腾文件系统重新挂载。

你QNAP瞎鸡儿改文件系统把别人数据全毁了，在云服务器上怎么恢复数据？下载整个镜像回来重新挂载吗？

不是我说，就算留个filestation能读写，能比得上filebrowser吗，搞这事把客户数据丢了激怒客户人家能恨你这牌子一辈子。

重启后raid损毁