想从公司,远程桌面到家里的 主力机(代号为 C 机),看看笔记啥的,一般不需要提交什么资料。
一般方案就是:控制端机 A,远程桌面到,家里 主力机 C。(家里还有一台 闲置机 B,看看能不能帮助提高安全性。)
如果实施远程桌面方案:
研究了一下站里,我做一个肤浅的解读:
所以,
但是看到很多案例,病毒木马感染能打穿局域网。想试问 机 B 访问 机 C 的笔记和图床有什么安全的服务? ==》就是一个局域网里面搞安全隔离的问题。
如果不实施远程桌面方案:
任意一台局域网内机器,将笔记部署为一个网页服务,只暴露这个端口和网页。外网的机器怎么访问这个内网网页,同时安全性比较高呢?
1
mohumohu 2023-05-05 11:21:32 +08:00
zerotier 开源可以自建,也不暴露端口。想安全暴露可以套个 cloudflare tunnel 。
|
3
az22c OP @mohumohu 不论开源还是闭源,个人对内网穿透和远程桌面不太信任,主要是因为这些给予的计算机权限太大了,把风险拔得太高。
|
4
iyiluo 2023-05-05 11:27:48 +08:00 1
开防火墙,只放行固定 ip 访问,如果是公司出口没有固定 ip ,可以放行网段,加上远程登录密码,足够安全了
|
5
weiweiwitch 2023-05-05 11:32:17 +08:00 3
没有绝对安全的系统。防的在好,某些安全技术在未来也有可能有致命漏洞。
所以说,所有方案都是在投入的时间精力(成本)和安全性之间做平衡。 把重要资料做离线备份,然后在自己有限精力范围内选择一个可行方案就行了。 太注重安全,这日子就没法过了(整天都处于焦虑中)。 |
6
mohumohu 2023-05-05 11:35:28 +08:00
@az22c 你这么说的话所有程序和方案都可能是不安全和有后门的,更别说闭源的程序了。远程权限并不是内网穿透给与的,而是你自己给的,你可以用标准用户远程连接,符合 UAC 的用法。
|
7
leaflxh 2023-05-05 11:38:39 +08:00 1
内网单独开一个 linux 虚拟机
用 iptables 禁止到内网的流量,只允许特定的端口 --- #新建一个隔离用的链 iptables -N ISOLATION #允许内网机器 192.168.1.10 连接该虚拟机的 ssh 服务和 https 服务 iptables -A ISOLATION -d 192.168.1.10 -p tcp -m multiport --sport 22,443 -j ACCEPT #拒绝所有的其他流量 iptables -A ISOLATION -d 192.168.1.0/24 -j DROP iptables -A ISOLATION -p all -j RETURN #以上规则应用到出站 iptables -I OUTPUT -p all -j ISOLATION iptables -I DOCKER-USER -p all -j ISOLATION --- |
8
xuelu520 2023-05-05 11:39:26 +08:00
你这个需求不需要远程呀,oneDrive 等等同步盘就行了
|
9
leaflxh 2023-05-05 11:41:36 +08:00
这样黑不到内网的机器,除非拿到 root 权限把防火墙清了,或者知道了这个规则,特地把发包的源端口设定为 22 或 443
|
10
az22c OP @leaflxh > 允许内网机器 192.168.1.10 连接该虚拟机的 ssh 服务和 https 服务
那我外网连到该 隔离机,随便选个相对靠谱的远程桌面方案就可以了吗? 我笔记仓库应该是放在主力机呀,那这个 隔离机 可以通过 git ssh 连接笔记吗?还是用的 u 盘传输笔记? |
12
az22c OP @xuelu520 #8 对呀。光是看笔记,靠笔记厂商的云服务或者云盘就可以了。这是绝大多数人已知的方案。我想问一下上述我这些不了解的方案,拿来实施一下。然后对比一下效果。
笔记云服务也不是十全十美的啊,主要在于要支付云服务费;然后大体积笔记仓库想弄到云上面,还是比较麻烦的呀 |
13
leaflxh 2023-05-05 12:16:21 +08:00
服务暴露在公网上肯定要开防火墙的。
如果不想学防火墙的话也可以试试端口敲门,就是只开一个端口,然后你连接过去,鉴权通过后它修改防火墙规则,把服务暴露出来。不过没怎么用过只看到过这个概念 https://www.freebuf.com/articles/network/281639.html https://lingwu111.github.io/%E7%AB%AF%E5%8F%A3%E6%95%B2%E9%97%A8%E6%8A%80%E6%9C%AF.html https://en.wikipedia.org/wiki/Port_knocking |
14
leaflxh 2023-05-05 12:18:10 +08:00
再就是把服务绑在 ipv6 上,目前“看起来”挺安全的,没什么人扫
|
15
brader 2023-05-05 12:23:16 +08:00
如果你有自己的服务器,懂用 frp 的话,我推荐你用这个,吊打其他远程软件,配置好后,无论是操作便利性还是连接质量,非常完美,我使用这个模式 3 年了,没出什么问题,也没中毒。
我使用的是 stcp 模式。 |
16
az22c OP @leaflxh 我笔记仓库应该是放在主力机呀,那这个 隔离机 可以通过 git ssh 连接笔记吗?还是用的 u 盘传输笔记?还是彻底物理隔离 wifi 隔离?
|
17
hack 2023-05-05 14:08:58 +08:00
mstsc 加个双因素认证
|
18
VirgilChen97 2023-05-05 14:14:30 +08:00 via Android
是不是直接用 VPN 就好了,我在公司就是直接 wireguard 回家然后直接内网地址远程桌面
|
20
Jhma 2023-05-05 15:20:21 +08:00 2
openvpn 方案,用 opnsense 开源防火墙搭建,可附加一个 OTP 二次验证,手机 APP 装谷歌验证器等,实现了用户+密码+证书+动态码高安全连接!
|
21
c5QzzesMys8FudxI 2023-05-05 15:31:13 +08:00
我是在家里软路由上开了个 Ss 节点,手机和 mac 用 QX ,在外面访问家庭网段 QX 默认走软路由的 Ss 节点。
|
22
registerrr 2023-05-05 15:37:49 +08:00
frp+远程桌面 最不用折腾, 最合适. 就是得有台公网服务器
密钥设长一点复杂一点, 安全的很. |
23
LnTrx 2023-05-05 15:44:43 +08:00
远程桌面的话虚拟机就行了吧,独立物理机的必要性没那么明显。虚拟机可以通过虚拟化软件的共享文件夹功能访问特定宿主机文件。
非远程桌面方案,部署网页服务的笔记放在虚拟化环境,然后 https 向外网公开不就行了。不放心的话在 nginx 反代再加一层密码验证。 |
25
LnTrx 2023-05-05 16:43:57 +08:00 1
@az22c 如果这都要考虑,那 A 上应用更可能有漏洞,导致 B 也可以攻击到 A 。
对比一下: 1. C 直接部署笔记服务,https 暴露外网 如果笔记服务有重大漏洞(比如登录界面可以访问到主机文件),会威胁整台机器 2. C 直接部署笔记服务,https 暴露外网,nginx 额外加一层密码 即使有重大漏洞,外界绕不过外层密码也难办(但有些 App 可能会不兼容额外的访问控制) 3. C 使用虚拟化部署笔记服务,https 暴露外网 如果笔记服务被攻破,虚拟环境可访问的信息会沦陷。 宿主的风险取决于虚拟化技术。对于虚拟机,逃逸是价值很高的漏洞,对于民用场景不太会遇到。Docker 可能需要加固。 4. C 直接部署远程桌面访问仅限本机的笔记服务,远程桌面暴露外网 如果远程桌面有重大漏洞,那会威胁整台机器。如果套一层隧道,那进一步取决于隧道协议和虚拟局域网的安全性。 5. B 部署远程桌面访问 C 仅限局域网的笔记服务,远程桌面暴露外网 首先取决于远程桌面的安全性。如果被攻陷,且局域网内有不设防 /高危漏洞的服务,可能会让运行该服务的机器进一步沦陷(除非额外限制)。B 本身的使用痕迹也可能成为跳板(比如保存了密码)。另外,局域网内其它设备也可能威胁笔记服务(除非额外限制)。 6. C 部署虚拟机运行远程桌面通过共享访问笔记,远程桌面暴露外网 如果远程桌面被攻破,虚拟环境可访问的信息会沦陷。是否能访问局域网其他设备取决于虚拟机网络的配置。 如果虚拟机存在逃逸等漏洞,会威胁到宿主机。 综合看下来,其实就是估计笔记服务出漏洞、远程桌面被攻破、虚拟机发生逃逸、隧道被攻破的可能性(同时考虑 ABC 自身以及虚拟局域网中其他设备等风险),组合出安全系数满足需求、同时不至于太麻烦的方案。个人认为民用场景下,虚拟机的隔离已经够安全了,实在不行加一层密码 /隧道。过于复杂的方案比较难以坚持,而且可能会增加新的风险点。 |
26
LnTrx 2023-05-05 16:45:57 +08:00
@LnTrx 如果这都要考虑,那 A 上应用更可能有漏洞,导致 B 也可以攻击到 A 。
修正> 如果虚拟机逃逸都要考虑,那 C 暴露在局域网的服务出漏洞更要考虑。这样的话,B 自然也可以攻击到 C 。 |
28
LnTrx 2023-05-05 17:02:19 +08:00
@az22c 我考虑得可能还不够周全。
另外想问下,你增加一个跳板,目的是为了保护笔记,还是宿主机。如果只是保护宿主机,那直接在 B 部署笔记不就完了。如果远程桌面方案想额外保护笔记,那还需要好的使用习惯。比如在 B 的浏览器里保存了密码,或者登陆了没退出,此时远程桌面被攻破,不也一样白搭。相比其它远程桌面方案,物理隔离对笔记的保护没有增加多少。 |
30
az22c OP |
31
LnTrx 2023-05-05 17:27:18 +08:00
@az22c 如果服务直接部署在 B ,就没必要再研究 B 、C 的互访,同时避免 C 局域网暴露造成的额外风险。担心 B 沦陷连累局域网的话可以在网关做额外限制,更重要的是加固其他设备的局域网暴露端口。(既然考虑 B 沦陷,那 B 自身防火墙禁止访问内网似乎意义有限)
另外的方案就是直接在 C 上运行虚拟机。比上述方案增加了逃逸的风险,当然民用很难碰到 0day 的逃逸攻击。但方便的点在于不用维护一台额外的设备,可以通过共享文件访问特定目录,同时控制虚拟机网络比较方便。可以在虚拟网络与宿主机通信(配完可以验证一下哪些宿主端口可访问),避免宿主机向真实的局域网暴露端口。 当然以上都是基于远程桌面的方案,如果是我自己还是更倾向于转发 https 。 写了半天注意到你怕的好像是勒索病毒,那把重要资料定期异机备份可能是更需要的保护。 |
32
thereone 2023-05-05 18:03:59 +08:00
搞的麻烦,哪有那么多翻车的。最简单就是部署一个 VPN 。你要有公网 IP 那就直接 VPN 回去就行,自行搭建 VPN 总不会被人攻破啊。不行就用内网穿透的 zerotier 这种,觉得不安全那就自建一个 moon 或者 leaf 节点。然后 B 和 C 之间要安全就上一个软防火墙如 pfsense opnsense 这类的或者用 esxi 导入山石网科的防火墙,虽然只有 30 天试用但是到差不多时间就快照一键还原就行。b 访问 c 就只在防火墙里面开启某些端口就行做到访问隔离。
|
34
sofukwird 2023-05-05 18:14:13 +08:00 via Android 1
不适合,微软远程桌面出过 0day 漏洞,不需要密码,只要你开了远程桌面端口就可以被黑客控制
如果你觉得自己很牛逼,能防所有 0day 漏洞,那你可以不用 VPN |
35
sofukwird 2023-05-05 18:15:56 +08:00 via Android
tailscale 客户端是开源的,你可以认为它没有明显的漏洞
|
36
bluehr 2023-05-05 18:18:05 +08:00 1
企业版 win10 mstsc + duo mobile 双因子认证 ,已经暴露 3389 端口多年,没被攻击过
|
37
AaIT 2023-05-05 18:25:01 +08:00 2
tailscale 组个内网不就行了,我们商用内部管理都用 tailscale 后台配置权限打上 TAG 想怎么控制怎么控制,tailscale 的域名可以申请免费的证书做个内网网站就行了,HTTPS 都齐全的,很完整的方案了
|
38
dann73580 2023-05-06 00:44:13 +08:00
Tailscale 基于 wg ,目前看 wg 的安全性还是挺有保障的。如果一定要信赖,那我选这个。家里电脑可以设置密钥过期时间,要安全就设置低一点好了。
|
39
lentrody 2023-05-06 01:33:25 +08:00
@sofukwird 难道 VPN 就不会有 0day 漏洞了?
部署安全性低的服务才需要 VPN ,微软远程桌面被无数人盯着,安全性不会比 VPN 差。 |
40
sofukwird 2023-05-06 08:00:36 +08:00 via Android
@lentrody 你能盯着黑盒你牛逼,微软远程桌面是闭源的
wireguard 的安全性是经过安全公司检验过的,目前来说没有发现明显的漏洞 |
42
aukus 2023-05-06 09:54:21 +08:00
说了这么多,都说 MS 不安全,有大佬科普下 RDP 被攻破的案例吗?
|
43
sheayone 2023-05-06 11:02:30 +08:00
我的经验,RDP 端口直接对公网开放,不管你改不改端口号码,都立马会引来一堆肉鸡来试密码,这个才是最大的安全风险;其次才是协议漏洞,这个需要勤打补丁。
增强 RDP 安全性的途径: 1. 增加一台 RDP Gateways ,相当于堡垒机; 2. 通过 over 其他安全通道,比如 VPN 或者 SSH Tunnel ,其中 SSH 仅允许密钥 /证书登录,安全性也可以得到提升。 互联网没有绝对的安全的说法,都是道高一尺,魔高一丈,保持警惕,安全防护实时跟进就是了。 |
44
wslzy007 2023-05-06 11:30:37 +08:00
@az22c
自己使用的话不要发不到外网。具体做法: 1 、使用工具建立 A to C 的 P2P 连接 2 、C 上无需监听端口 3 、只有从 A 可以访问 C 如上就非常安全了,至于工具如果只是远程端口映射,无需 vpn ,推荐使用 SG:github.com/lazy-luo/smarGate |
45
hamsterbase 2023-05-06 12:12:40 +08:00 via iPhone
电脑 a 安装 tailscale
电脑 b 安装 tailscale 问题就解决了 |
46
huihuilang 2023-05-06 14:15:06 +08:00 via Android
我用 vpn+内网远程桌面解决,技术不行公网开端口怕怕的
|
47
xPKK1qofAr6RR09O 2023-05-08 14:54:37 +08:00
不适合,你猜 CIA 手里有没有一堆 0day 漏洞
|
48
mm2x 2023-05-09 19:34:36 +08:00
我一般是 ACL 做策略 只允许白名单 IP 通过。或者你有环境的话使用 IPv6
|
49
cdh1075 2023-05-09 22:31:38 +08:00
有一个 vps 上的 windows 11 ,全关系统防火墙,全关 vps 商的硬件防火墙,3389 暴露公网,两年前发现基本每天有好几百的链接请求,那个主机也不重要,所以我就故意一直这么放着做个实验,除了及时更新补丁,啥格外的安全措施不加,两年过去了,没被打穿。
3389 的安全风险和 ssh 是一样的,一是弱密码,二是安全 bug 。 弱密码可以通过加证书解决,安全 bug 遇到的几率和中彩票差不多。 |
50
a578800641 2023-05-17 10:19:23 +08:00
@huihuilang 跟你一样,我也是这样处理的,,
|
51
yijiangchengming 2023-05-31 19:02:32 +08:00
都上 VPN 了,为什么不试试 WireGuard 呢?
|
52
rnv 2023-10-27 14:40:57 +08:00
有公网 IP
弱密码 开放远程桌面 是不安全的 我已经试过了。前几天在 ikuai 后台看到一个可疑 IP 通过远程桌面跟我 PC 建立了很多连接 |