V2EX › xinghen57 的所有回复 › 第 3 页 / 共 31 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 31

❮

❯

77 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@dhuzbb #49 仅从理论角度，只要你连接的第三方设备能联网，数据是可以摆渡出去的。
当然，在实践中，你说的局域网使用，我个人是倾向认为风险可忽略（注，可忽略不等于没风险）。

我觉得从理论角度界定风险边界，然后根据实际应用场景和自身风险偏好和能力去做决策时比较好的。因此，讨论应该加上限定条件，比如理论角度、实践中、不考虑数据摆渡风险等情况。

78 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@unklity #46 确实。理论上只断网还不行，还要只进不出才理论完美。

安全审查和反审查就像矛和盾，目前看是不存在一方完全胜过另一方的情况。更何况更多案例中，最薄弱的环节反而是人。

78 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@dhuzbb #16 “极空间系统层面做了功能，可以限制外网登录和访问，只在局域网内部使用”，这不是真正的局域网使用。
你在一个不可信的 nas 系统上使用他的功能，这是掩耳盗铃。

78 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@unklity #31 “假设开源软件公开仓库的源代码经过审查”，xz 后门是个例外。它不是通过源码审核发现的。
后面的思路很赞。

78 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@lxh1983 #39 抱歉狭隘了。你说得对。如果理想状态下，nas 系统上无能为力。加软路由理论上可以应对。

但是吧，对方留的后门也不可能达到世界顶尖水准，所以我还是认为通过防火墙截断可能的后门是比较泛用的防御手段。
之后可以留意各进程和对网络流量分析。只要有后门，通常都会有征兆，比如定期向特定服务器发送保活信息等。发现后做具体应对吧。毕竟家庭网络出口的控制权在用户。如果一个后门只能被主动触发，使用时本身就存在不确定性，这类只能认栽，基本没什么办法。

78 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

@lxh1983 #34 有后门没问题，只要后门没法联网，就和物理隔离一样的效果。
比如 nas 自建 nextcloud ，端口 8888 。局域网的防火墙只放行 8888 端口的进出站，这样后门理论是没法出站，外部理论也无法连接后门。端口已经被占用了。
当然，后门可以关闭 nextcloud 再使用 8888 端口，这样比如有记录，查日志就能发现端倪。
我目前好像没听说一个端口被可以被不同程序同时占用的情况，这样后占用的会提示端口已被占用。

另外，你说的 api ，在出站时也是需要分配端口的，这是系统规定的。除非系统提供隐藏端口。但防火墙白名单模式同样会禁止隐藏端口通信。

79 天前

回复了 t4we 创建的主题 › NAS › 原来云盘文件在 Server 是不加密的

@xiaochen3 #77 hash 是需要实时计算的吧。没听说文件头或尾分配字段存储 hash 。
此外，如果加密前的 hash 文件云端有，加密后文件秒传了，不说别的，你再下载下拉的文件一定是没加密的。

79 天前

回复了 t4we 创建的主题 › NAS › 原来云盘文件在 Server 是不加密的

@xiaokangz #18 假设你说的逻辑成立，请问妙传后的文件还是加密后的文件么？
比如本地文件 A ，云盘也有 A ，两者 hash 相同。现在你对 a 加密，重新计算的 hash 一定是改变的。假如现在秒传检验加密后的文件，认为它和云盘中的文件 A hash 相同，秒传完成。那么请问，现在云盘 A 的文件是加密前的 A ，还是加密后的 A ？

79 天前

回复了 Tiking 创建的主题 › NAS › 关于 nas 系统的信息收集

提个思路，求谈论可行性：使用防火墙仅放行 nas 指定服务端口，理论上可以使后门失效。

92 天前

回复了 szsgz 创建的主题 › Android › 目前最靠谱的安卓机

我说个手机吧，绝对靠谱：领导的手机

92 天前

回复了 xfy369 创建的主题 › 奇思妙想 › 信用卡账单日排序产品？

自动还款，省心省力

197 天前

回复了 xinghen57 创建的主题 › 问与答 › 问个 QQ 邮箱注销问题

@datocp #9 老号遇到类似验证逻辑问题，算了，不用了。
想了想，email 还是用 163 吧，好歹不会出现类似问题。