有一个 IPv6 防火墙总开关就够了 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
LnTrx
V2EX    宽带症候群

有一个 IPv6 防火墙总开关就够了

  •  1
     
  •   LnTrx 2022-02-13 15:45:51 +08:00 15666 次点击
    这是一个创建于 1345 天前的主题,其中的信息可能已经有所发展或是发生改变。

    2022 年了,很多家用路由器还是没有 IPv6 防火墙的开关,这不应该。
    但也有不少人希望路由的防火墙能像 IPv4 那样提供开放端口、控制映射等高级功能,楼主觉得大可不必。

    原因如下:

    1. IPv4 下暴露端口最大的威胁是被人扫到,而 IPv6 的 SLAAC 和隐私扩展机制使得终端极难被外部暴力扫描发现(不含网关)。现代操作系统通常自带有防火墙,即使 IPv6 用户的主动访问被探测并发起回访,只要没有乱改配置风险也不大。

    2. SLAAC 和隐私展机制使得用户的 IPv6 地址是经常变化的,用户要么需要设法固定地址,要么就得不断调整防火墙配置,无论哪种都非常麻烦。(楼主还没找到可以根据终端 MAC 自动配置的方案,如有还请指出)

    3. 点对点直连才是互联网本来的样子。当用户被 IPv4 NAT 保护惯了,突然回到无阻碍直连的状态反而没有安全感,这才是反常。如果为了顺从过去的习惯,在网关默认屏蔽入站连接,那么当需要开放端口时就又得搞出一套适用于 IPv6 的打洞机制。应该没有人希望在 IPv6 时代还要折腾 UPnP 、NAT-PMP 、Hole Punching 之类的事情吧?

    需要指出的是,在 IPv6 地址长期固定的服务端场景下,网关防火墙的精细控制还是有意义的。
    如果有考虑不周的地方,欢迎交流讨论。

    66 条回复    2024-12-24 16:54:26 +08:00
    duke807
        1
    duke807  
       2022-02-13 16:02:37 +08:00 via Android
    > 应该没有人希望在 IPv6 时代还要折腾 UPnP 、NAT-PMP 、Hole Punching 之类的事情吧?

    有人,那就是有的互公司,譬如於
    duke807
        2
    duke807  
       2022-02-13 16:05:46 +08:00 via Android
    譬如於 TeamViewer 的公司,如果 ipv6 可以直,那公司就要倒了

    ipv6 大工程是好西,反 ipv6 外麻的事情

    ipv6 路由器不允外部主接部的防制,而且不掉,是垃圾路由器的尿性吧?海外路由器不存在的吧?
    delpo
        3
    delpo  
       2022-02-13 16:52:58 +08:00
    >现代操作系统通常自带有防火墙

    至少安卓的防火墙默认是允许入站流量的

    >SLAAC 和隐私扩展机制使得用户的 IPv6 地址是经常变化的

    设备的 ipv6 固定地址一般是由网关下发前缀+EUI64 计算后缀组成的,其中只有前缀会经常变化。linux 下 ip6tables 可以使用诸如“IPv6 地址 /::ffff:ffff:ffff:ffff”的格式进行后缀匹配来指定设备
    cwek
        4
    cwek  
       2022-02-13 16:55:34 +08:00   2
    不确定,至少 dd-wrt 的 IPv6 默认 ip6tables 是禁止外网 forward (除 Icmpv6 ),也没有页面开关。

    openwrt 的防火墙规则好像也默认 REJECT 掉 forward 。

    不要太过于信赖终端的防火墙能力,可能很多物联网设备根本没有这玩意(手动狗头)
    acbot
        5
    acbot  
       2022-02-13 17:18:46 +08:00
    @delpo 是这样的。
    NXzCH8fP20468ML5
        6
    NXzCH8fP20468ML5  
       2022-02-13 18:24:29 +08:00
    SLAAC 不是安全保障,在临时 IPv6 地址存活周期内发起攻击完全可行。

    只提供 iptv6 总开关肯定是不行的,后缀匹配放行一定要有。我看到路由器做的最好的就是 openwrt 和华硕固件。
    比如我信任 NAS 防火墙,就把 NAS 全部端口放行在公网上。其他没有完整防火墙的设备,只允许某些端口入站。

    ipv4 时代的 UPNP ,端口转发,DMZ 失去了意义,但还需要一个协议允许客户端主动请求防火墙放行 /阻止自身某个端口入站。
    fetich
        7
    fetich  
       2022-02-13 18:33:41 +08:00
    说起 SLAAC ,感觉群晖的 DSM 获取 v6 地址是没有临时地址一说的,后面一半始终没变,就是 mac 地址
    datou
        8
    datou  
       2022-02-13 18:41:01 +08:00
    我用过的 WiFi 路由器都有 SLAAC 和 DHCPv6 的切换开关

    倒是 ipv6 防火墙确实有些路由器没有

    所以我选择主路由用 openwrt 桥接 WiFi 路由器
    Overfill3641
        9
    Overfill3641  
       2022-02-13 18:54:26 +08:00
    @duke807 #2

    其实禁止连入也是可以 UDP 打洞的,IPv6 因为很少会采用 NAT ,故 IPv4 对称 NAT 打洞不了的情况不常见,因为是打洞,系统已经安装了应用且需要应用主动发送数据包,不是一种风险。

    TeamViewer 支持 IPv6 打洞链接,只是没支持输入 IPv6 地址链接。如果愿意暴露端口一大堆远程软件都可以适配这个基本功能。自用 RDP 都可以。

    会动手的折腾的自己 DIY 固件就好了,一般人 BT 、游戏联机、傻瓜式远程软件都不需要主动暴露端口。(并不是说不允许关闭防火墙是一种好主意)。
    LnTrx
        10
    LnTrx  
    OP
       2022-02-13 19:09:42 +08:00
    @delpo
    安卓设备对防火墙的需要不大( https://www.quora.com/I-know-I-dont-need-antivirus-for-Android-But-do-I-need-a-firewall ),更何况连蜂窝数据的时候也不可能去上级网关配置防火墙
    我说的就是后缀的变化,PC 端要把设备的后缀固定成 EUI64 一般需要改配置,移动端则更麻烦
    boris93
        11
    boris93  
       2022-02-13 19:20:59 +08:00 via iPhone
    @fetich #7 群晖默认不开启隐私保护,也就是说默认没有临时地址,得自己改配置文件
    fetich
        12
    fetich  
       2022-02-13 19:31:53 +08:00
    @boris93 当时在网上检索了一阵,好像没人在意这件事。有群晖官方的修改指南么,还是说需要联系支持?
    LnTrx
        13
    LnTrx  
    OP
       2022-02-13 19:51:47 +08:00
    @delpo 顺便一提,固定的后缀也会成为隐私的风险点,特别是个人电脑。
    例如用户下载了某个不正经的 BT 种子,那 IP 地址的行为可能被记录甚至公开(比如 iknowwhatyoudownload.com )。一段时间以后,用户又访问了某个正经网站,因为实名制,后台知道了你后缀和身份的关系。这样,之前的行为也可能与用户的真实身份相关联。在隐私扩展下,只有在相近的时间这样干才容易被关联。但如果使用了固定的后缀,那即便隔了一年也可以被关联,直到用户主动更换。
    另外,EUI64 后缀包含设备的 MAC 地址,对厂商而言也是一个可用于追踪的信息。
    所以如果使用防火墙放通固定后缀的方案,那可能得把需要放通的服务都集中在专门的设备(如 NAS )与个人电脑隔离,并且仅把该设备的地址后缀固定成随机选定的值。
    LnTrx
        14
    LnTrx  
    OP
       2022-02-13 20:07:58 +08:00
    @cwek 物联网设备确实可能根本没有防火墙。不过这种物联网设备通常也没有隐私扩展,后缀是 EUI-64 定死的。
    这么说我们需要的其实是黑名单防火墙(误)
    LnTrx
        15
    LnTrx  
    OP
       2022-02-13 20:17:00 +08:00   1
    @fetich Linux 通常的做法是在 /etc/sysctl.conf 设置

    net.ipv6.conf.default.use_tempaddr=2 ( https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

    不过我没有在群晖里试过
    fetich
        16
    fetich  
       2022-02-13 20:44:22 +08:00
    @LnTrx 感!我在後添加回覆!
    duke807
        17
    duke807  
       2022-02-13 21:10:07 +08:00 via Android
    @v2tudnew 既然不想享受 ipv6 的便利,那推 ipv6 的意何在? ipv4 全部改用可以打洞的 nat 就好了啊,也不存在地址不的情了。。。
    delpo
        18
    delpo  
       2022-02-13 22:22:05 +08:00
    @LnTrx 所以现在都是临时地址+EUI64 地址同时存在,临时地址用于访问外网,固定地址用于作为服务器地址
    可以看一下 windows 默认就是可以获取多个 ipv6 地址的,linux 一个网卡也可以获取多个 ip
    Overfill3641
        19
    Overfill3641  
       2022-02-13 22:25:28 +08:00
    @duke807 #17 v4 NAT 打洞成功率不高了,到处是 Symmetric NAT ,要么就是 Port
    Restricted Cone NAT ,甚至还有端口内外不一致的 Full Cone NAT 。再说又不是不让你用,你路由器问题怪 v6 这不合适吧?
    boris93
        20
    boris93  
       2022-02-13 23:40:01 +08:00 via iPhone   1
    @LnTrx #15 对,就这个
    @fetich 我是把 default 换成 eth0 还是 ovs_eth0 了
    LnTrx
        21
    LnTrx  
    OP
       2022-02-14 00:27:59 +08:00
    @delpo Windows 和部分 Linux 类操作系统的默认采用了 stable privacy addresses ( RFC7217 ),当网络环境变化时“固定”IPv6 地址的后缀也可能改变,需要用户配置才能改成 EUI64 或者固定值

    顺便一提,如果防火墙只放通了固定地址,那主机内软件在开启端口时会面临两难:
    1. 让外界连接临时地址,那么端口在外网无法直接访问,需要增加复杂性、引入 v6 打洞机制
    2. 让外界连接固定地址,那么就相当于架空了隐私扩展,这样做的软件多了就可能关联身份
    NXzCH8fP20468ML5
        22
    NXzCH8fP20468ML5  
       2022-02-14 00:53:48 +08:00   1
    @fetich 群晖这类 NAS 本来防火墙就设计完善,只要不搞弱密码等窒息操作,面对公网完全没问题。引入临时地址还增加了访问难度,所以没有人在意临时地址也是很正常的事情。类似还有 Debian, Ubuntu 等的 server iso 都默认没有开启临时 IPv6 地址。
    LnTrx
        23
    LnTrx  
    OP
       2022-02-14 01:31:19 +08:00
    @LnTrx 更正:Windows 默认采用的是 RFC4941 的方案,地址随机但相对稳定。部分 Linux 类操作系统默认用的是 RFC7721 ,会随着网络环境(如前缀)而变化。
    duke807
        24
    duke807  
       2022-02-14 04:57:33 +08:00 via Android
    @v2tudnew 我自己的路由器然不用垃圾,只是我程序,遇到用垃圾路由器的用,日後做品麻很多。
    Overfill3641
        25
    Overfill3641  
       2022-02-14 06:44:14 +08:00
    @duke807 #24 有什么麻烦?监听端口应该让用户知道自己在做什么对吧?例如远程之类的,就那么监听用户又不知道,这不是安全风险吗?那么让用户自己解决问题好了。
    loopinfor
        26
    loopinfor  
       2022-02-14 09:58:59 +08:00
    我有个疑问。虽然 IPv6 数量多难以暴力扫描,但是是不是还可以主动搜集呢?
    比如我做个垃圾网站页面,通过 SEO 或者 JS 植入吸引很多人来浏览页面,然后记录访问者的 IP 是不是就可以得到一个有效 IP 池了?而且理论上这个 IP 池还可以附带 OS 信息是吧?
    delpo
        27
    delpo  
       2022-02-14 10:06:10 +08:00
    @LnTrx 我看了一下,windows 好像默认的确默认没有开启固定后缀

    不过你说的隐私问题我感觉是矛盾的,如果你想在暴露某个端口或者地址供公网访问,那自然就要使用相对固定的地址,才能方便使用。那为什么又要考虑隐私问题呢?如果你觉得可能会暴露 mac 地址,那也可以手动使用 dhcpv6 进行地址分配。
    xPKK1qofAr6RR09O
        28
    xPKK1qofAr6RR09O  
       2022-02-14 11:27:44 +08:00
    其实不需要太纠结动态后缀的问题

    我用 routeros ,对于非常规的端口比如 bt ,没必要放行到具体的后缀,全局放行就好,毕竟很少会有两台机子撞端口

    对于可能存在相同端口的服务,可以根据网口或者 vlan 放行。比如 ap 网口下都是智能家居和娱乐设备,全部 reject ,esxi 网口下,或者 esxi 中某个 vlan 可单独放行
    LnTrx
        29
    LnTrx  
    OP
       2022-02-14 13:33:53 +08:00
    @v2tudnew 监听端口向用户请求授权可以在操作系统内实现,比如现在的 Windows Denfender Firewall 。
    IPv6 的高级防火墙即使存在,家庭用户中也只有很小的比例会配置。IPv4 时代的自动端口规则协议大多不适用 IPv6 ,即使未来出现了,那还要考虑不同路由厂家的支持情况、如何配置多级路由等。可以说 NAT 的老毛病很多都回来了。
    IPv6 下的打洞相比 IPv4 NAT 确实会简单一点,但作为开发者,肯定还是希望少碰到这种事情。

    @loopinfor 这就是我说的“主动访问被探测并发起回访”,也是隐私扩展提出临时 IPv6 地址的原因。

    @delpo 典型的服务端需求建议用固定地址,典型的客户端需求建议用动态地址。但是还存在很多客户端需求比如 BT 、Sync 、VoIP 、PS4 ,他们既需要放通端口以提供便利,又可能有隐私顾虑不宜长期固定。家庭宽带的前缀本来就是会变的,如果不是要配置防火墙白名单,后缀的变动本来也不会增加多少问题。路由设成 DHCPv6 不是很推荐,因为地址空间小、安卓设备可能获取不了 IPv6 等,还不如直接固定后缀。
    duke807
        30
    duke807  
       2022-02-14 13:53:18 +08:00 via Android
    @v2tudnew 和端口是否用知道有

    我是上面程桌面的例子,可以主接的,A 用把自己的 ip 和 pin 告 B 用,然後 B 就可以助 A 完成一些操作。

    如果不能主接,然也可以使用 serverless webrtc ,但是用自行交 ice 打洞会比分享 ip 地址麻很多,否又要引入第三方服器。
    即便引入服器,也限制人只能使用 webrtc ,用其他 web 不支持的的,就法使用 h5 面跨平台,下是 android ios windows linux 不同平台的程序要。
    而且,一些低成本的硬件,譬如安防像 /物陪伴器人,硬件也跑不 headless webrtc 。

    最後充一下安全,如果不提升端本身的安全性,靠路由器不外界通 ipv6 主部主的意不大,病毒木可以主接外界,而且局域一台器中招,其它器都要完蛋。
    Overfill3641
        31
    Overfill3641  
       2022-02-14 15:38:17 +08:00
    @duke807 #30 你这是要求用户裸奔来达到减少你代码量的目地啊。防火墙是一定要有的,最多也就做成允许某个 IP 开放某些端口,绝不能完全不设防。不允许开放端口这点我是一样喷的,但本身不关 v6 的事情。
    病毒木马虽然可以办到,但也必须先被下载运行了,这和你把门打开任何人都可以进完全是两码事,一个是随便进,一个是要先和门卫说一句哪个人几点有预约!
    IPv4 NAT/防火墙下也需要用户自行解决端口开放问题,v6 只是解决了用户拿不到公网 IP 的问题,不要把事情复杂化。
    Overfill3641
        32
    Overfill3641  
       2022-02-14 15:45:53 +08:00
    @LnTrx #29 win 那个防火墙就算了,绝大部分用户都是无脑同意的,一个不需要联机的单机游戏都会请求防火墙权限。
    开发者就不应该去管路由器防火墙的问题,这都是用户自行解决的事情。难道公司不允许连入就把网管干了?你们只需要在 UA 上提示端口开放检测就可以了。
    IPv4 NAT 下 UPnP 也存在各种兼容问题,开发者能穷举所有问题解决吗?
    duke807
        33
    duke807  
       2022-02-14 16:07:07 +08:00 via Android
    @v2tudnew
    是了方便所有人
    而且在一定程度上保了用私,譬如我作用,於安防像,我只意使用不需要接入商公司服器的源像,不可能把小米的商像安在家自己光屁股走走去

    防火我是可的,自己做品,品明指用配置防火就行
    『不允许开放端口这点我是一样喷的』是核心,意一致就好
    cest
        34
    cest  
       2022-02-14 16:15:19 +08:00
    @duke807 #33 目前有好用可刷 openipc 的 ipcam 吗?
    duke807
        35
    duke807  
       2022-02-14 16:21:17 +08:00 via Android
    @cest 抱歉,不了解 openipc ,我之前用 莓牌 zero diy 了一易的,只能合用
    LnTrx
        36
    LnTrx  
    OP
       2022-02-14 17:05:09 +08:00
    @v2tudnew
    Win 的防火墙好歹还需要同意,UPnP 这种开了以后就是自动配的。你觉得开发者就不应该去管路由器防火墙,但是用户用不了首先会找开发者而不是路由器。即使 IPv6 支持比较好的那些路由器,想让普通用户简单学会也称不上容易,用户搞不懂说不定还是全部关掉了事。

    安全与便利是一对矛盾,如何取舍需要智慧。我发本帖的目的在于指出,在 IPv6 下端口暴露被攻击的风险大大降低,而正确配置防火墙的门槛比 IPv4 NAT 还要高,否则很多 IPv6 的优势就无法发挥。对于家庭的应用场景,默认放通入站相比默认拒绝设置例外,对开发者和用户来说都是更好的权衡。在 IPv6 下还要搞防火墙,是不信任硬件自身的防火墙,所以再加一道额外防护措施的小众专业级需求,我觉得不应该成为通行做法。当然,各位分享自己的权衡考量,也有助于大家做出更好的判断。
    Overfill3641
        37
    Overfill3641  
       2022-02-14 17:45:10 +08:00
    @LnTrx #36 你这种需要主动暴露端口通过 IP 才能访问的产品(完全无中心化),也就是说用户还需要配置 DDNS 才能运行,你觉得这算小白产品、用户会完全不知道配置端口开放吗?
    然后你提出关闭防火墙,让用户完全暴露出来,依赖随机地址来确保安全性,那么用户访问了别有用心的网站然后被攻击,这算谁的?你这是从厂商为了安全封死防火墙的极端到为了自己方便写代码完全暴露的另一个极端。
    UPnP 是自动化,但应用正常情况下只会暴露自己的端口,操作系统那么多漏洞你来个完全暴露,那么你自己的服务器也是全端口完全暴露的吗?
    你都提出让厂商关闭防火墙了为啥不去搞个联盟弄个 IPv6 时代的 UPnP 类似的功能出来呢?
    LnTrx
        38
    LnTrx  
    OP
       2022-02-14 19:33:55 +08:00
    @v2tudnew 主动暴露端口通过 IP 才能访问并不等于 DDNS ,例如 BT 、IPFS 、通话、对战等产品也用得上,不一定是专业级需求。
    UPnP 和 NAT-PMP 是安全和便利性权衡的经典案例( https://docs.netgate.com/pfsense/en/latest/services/upnp.html ),这表明自动配置端口的需求是广泛存在的,为此可以牺牲一点安全性。
    用户访问恶意网站被回访,然后被攻陷的可能性当然存在。对于应用程序级的高危漏洞,如果已经存在 IPv6 时代的类 UPnP 机制,那也可能会被自动放通而中招,网关有没有防火墙可能区别不大。
    至于操作系统的高危漏洞,这一般是大新闻(如永恒之蓝),有很多限制条件(比如 Win 防护墙 445 的入站规则限定为本地子网),会很快发布升级补丁。未公开的 0day 不太可能攻击普通用户。而且恶意网站的攻击需要有主动访问恶意网站的行为,不像 IPv4 那样会“躺枪”。所以我觉得风险是可控的,并不是为了方便而忽视危险的极端。
    我主帖已经提到,服务端场景下 IPv6 地址是长期固定的。加之地址会被 DNS 公开,有一个高级的网关防火墙还是有意义的。
    Overfill3641
        39
    Overfill3641  
       2022-02-14 20:09:20 +08:00
    @LnTrx #38
    BT 、IPFS 、通话、对战 这些都可以通过 UDP 打洞连接(已经在这么用了)
    你的观点是因为某些应用本身的漏洞可以被攻击,所以就关闭整个防火墙?这就像本身只有一两个地方漏水,你倒好直接把屋顶掀了(顺便让对方攻击难度降低到几乎为零)。我也不知道该怎么说你了,让别人自己思考吧。
    发现漏洞到弄出补丁到绝大部分用户都安装补丁这需要多少时间?你觉得风险是可控的因为不是你中毒罢了。你想这么干建议你先从软件控制把人家防火墙关闭做起,不要让别人来背黑锅。
    Overfill3641
        40
    Overfill3641  
       2022-02-14 20:09:54 +08:00
    @v2tudnew #39 IPFS 不了解,补充一下。
    Overfill3641
        41
    Overfill3641  
       2022-02-14 20:15:08 +08:00
    对了,虽然临时 IP 那种随机攻击的不会知道,但被访问端,中间设备(主要房东及各类公共 WIFI )都是知道的,我是不知道你哪来的自信说风险可控。
    LnTrx
        42
    LnTrx  
    OP
       2022-02-14 23:06:28 +08:00
    @v2tudnew
    对,是可以 UDP 打洞,只不过各环节都要增加复杂度。比如在 BT 中,就需要一个没有防火墙的 peer 做中介。( https://libtorrent-discuss.narkive.com/HqyhMO7B/libtorrent-does-libtorrent-support-hole-punching )如果大家都指望打洞方案,那可连接性就可想而知了。
    顺便一提,NAT-PMP 有支持 IPv6 的后继者( Port Control Protocol ),但不太清楚目前路由支持的情况。

    参考之前的永恒之蓝,微软已经发更新之后 WannaCry 才开始传播,而且主要是内网扩散。IPv6 回访攻击要能实现,对漏洞的要求应该更高。相比之下,防止应用程序漏洞的作用倒相对大一点。如果某程序开了没有限制来源的公网访问端口、通过了系统防火墙的许可、出现了未修复的危险安全漏洞、没有配置打洞机制或防火墙例外,同时用户主动访问的网站或中间的网关被攻击者掌握,且攻击者进行了扫描并正好知道这个漏洞,那有白名单防火墙会更安全。
    我的意思是说,网关白名单防火墙的方案对用户和开发者增加了太多复杂性,但提升的安全性不大。操作系统的防火墙依然存在,所以掀屋顶的比喻不是很恰当,要我看更像是把围墙拆了变街区。

    你提公共 WIFI 的场景我有点不理解。如果你在考虑把设备放置于陌生网络中的风险,那更应该加强设备自身的防护(零信任思想),而不是依赖网关来营造“安全”的边界。
    Overfill3641
        43
    Overfill3641  
       2022-02-14 23:54:43 +08:00
    @LnTrx #42
    你自己举例的都不说直接暴露不安全了......临时 IPv6 主要目地是隐私问题。
    你说永恒之蓝,那 Windows RID 劫持 这个漏洞呢,发现都长达十多个月了,还有很多都不记得了的漏洞。开发者不关心用户是否有安全问题我能理解,但鼓动关闭防火墙那又是另一回事了。
    BT 真正的问题是无公网 IP 可用而不是用户会不会配置的问题,IPv4 的端口映射给新手也不会用还是得依赖自动映射,不如让厂商早点支持才是解决方法。

    我很好奇你那不用 DDNS 又不能中继、打洞非要 IP (每次连接还得看 IP 是多少,然后复制粘贴,我感觉很神奇)输入连接,用户又是小白的软件到底是啥? BT 这个例子可不适合,这个不需要用户配置 IP 地址。
    Overfill3641
        44
    Overfill3641  
       2022-02-15 00:00:33 +08:00
    >>操作系统的防火墙依然存在
    问题是用户你给他个是否选择,他一定会选择是,那你说这个操作系统防火墙有用吗?
    而且,那些啥智能设备有防火墙吗?你就这样直接暴露出来?
    Overfill3641
        45
    Overfill3641  
       2022-02-15 00:15:04 +08:00
    算了,上面的当我没回好了,如果厂商真全这么搞,就交给时间验证吧。
    LnTrx
        46
    LnTrx  
    OP
       2022-02-15 00:26:05 +08:00
    @v2tudnew 没有绝对的安全,我的举例是在说明安全和方便的取舍问题
    Windows RID 劫持是公网暴露端口就能被利用的漏洞么?我在说的是能使公网回访攻击产生危害漏洞出现的概率。我不是开发者,只是在实践中产生了对 IPv6 的防火墙策略的见解。

    最后这个问题没看懂,什么叫“需要用户配置 IP 地址”,我什么时候提出过这个需求?
    LnTrx
        47
    LnTrx  
    OP
       2022-02-15 00:45:46 +08:00
    @v2tudnew 当然,你的见解也具有启发性。可以设想未来有一天,路由器和各类应用都广泛支持 PCP 机制,用户无需手动添加例外同时又可以进行管理,那默认禁止入站会是一个更优的选项。在这一天到来之前,我还是觉得有一个 IPv6 防火墙总开关就够了。
    Overfill3641
        48
    Overfill3641  
       2022-02-15 01:04:03 +08:00
    我可没说绝对的安全性,路由器防火墙的存在是隔离私网与广域网的屏障之一。
    永恒之蓝发现的快是因为它是破坏性的(没瞎的人都知道有问题)。

    我也说说我的体验,用户配置难点在哪?路由器能检测出设备名称、MAC 地址吧,按名称\MAC (临时地址也有一样的 MAC )配置端口开放,这是功能没做好的问题。
    默认禁止连入、允许应用自动配置,防御永远是被动的,适当过滤不必要的能减少很多麻烦,这才是意义上的取舍,毕竟要允许任意 IP 连接的应用就那么多,像联机、VOIP 一对一的少数靠打洞完全够了,v6 没有 CG NAT ,没那么多复杂场景。
    LnTrx
        49
    LnTrx  
    OP
       2022-02-15 01:36:48 +08:00
    @v2tudnew
    我也是因为曾经想沿用 IPv4 的经验,发现配置异常繁琐才产生如此见解的。比如主帖里提到的“可以根据终端 MAC 自动配置的方案”,就是曾经试图寻找但未能实现的尝试。
    只不过面临这样的困难,你我设想的路线不同。你的设想是强化私网与广域网的屏障,构造一个安全的内网,通过更多功能改善用户的体验。我的设想是取消网关上的安全边界,按照公网的标准防范,通过 IPv6 的隐私扩展和强化终端的建设来维护安全。现况与这两个设想都有一定的距离,未来会怎么发展,也只能交给时间了。
    xPKK1qofAr6RR09O
        50
    xPKK1qofAr6RR09O  
       2022-02-15 01:37:20 +08:00
    防火墙又不是只用来做端口转发的,哪怕不存在 ipv4 的地址枯竭,不存在 nat ,openwrt ,ros 的 ipv4 防火墙就会比现在更简单么,并不会。

    不要指望默认开放入站能成为主流,正经厂商,不可能给你默认开放入站,谁都不能保证有意外,出了事,他家的品牌都得掉价。恰恰相反,routeros 出厂给你整了 20 多条 ipv6 的默认防火墙规则,已经告诉了你什么才是重要的:安全

    8-9 成以上的网民,压根不关心自己的端口有没有开放出去,他们连端口是什么都不知道,能正常上网就完事,谁关心开发者网路连通性好不好搞定。但是他们会共同关心的还是:安全。如果你跟他们说,网上任何人都有可能直接访问到你家的摄像头,你看他慌不慌就完事了。

    现在应该说比以前任何时候都更注重数据安全、隐私保护。以前国产路由出厂密码都整些 123456 之流,现在都得让你自己设置,这才是进步。
    baobao1270
        51
    baobao1270  
       2022-02-15 07:43:55 +08:00
    第三点说的很对,IPv6 本来就是 IP 网络本来的样子。大多数人都已经习惯了有 NAT 的网络,不知道“路由”是什么东西,以为 LAN 本身就是带 NAT 的。

    但是正是因为没有了 NAT ,所以以前那种“反正有 NAT 要什么防火墙” 的思路应该结束了。正是因为没有了 NAT ,所以才需要对防火墙进行精细的控制。这个与 UPnP 、Hole Punching 无关,IPv6 防火墙要做的是 iptables 之类的事情。

    “在 IPv6 地址长期固定的服务端场景下,网关防火墙的精细控制还是有意义的。”这句话正是“开放端口、控制映射等高级功能”存在的意义啊。而且 IPv6 不固定不是 IPv6 的问题,是 SLAAC 的问题。对于小白需要的是快速配置、预制的防火墙规则和 SLAAC ;但是对于我们这些喜欢折腾的人来说,还是需要高级的防火墙功能和 DHCPv6 的。如果一个产品想要覆盖更多的用户,还是需要做这些功能的,尤其是面向“发烧友”的产品。正所谓“我可以不用,你不能没有”。

    另外我觉得 SLAAC 本身也是面向大众的一个东西,对于喜欢折腾的人、还有需要对外提供服务的情况,使用 DHCPv6 才是正确的做法。把网络的安全交给 SLAAC ,无异于 IPv4 时代将网络安全交给 NAT 。
    LnTrx
        52
    LnTrx  
    OP
       2022-02-15 13:04:46 +08:00
    @baobao1270 我是觉得 NAT 反而让大家习惯于“安全”的内网,一定程度上忽视了终端安全的建设。这样在终端移动到陌生网络或在网关配置失误时反而会出现更大的危险。

    自动化端口暴露的需求还是广泛存在的,要穿越的就是 ip6tables 。

    家用场景的前缀总是会变,本来就要适配动态的 IP 报告机制,所以在这里我不当作“长期固定”。当然你表达的可能是“后缀长期固定”。正如前面所说的,在端口暴露自动配置机制还不怎么可用的现在执行白名单防火墙,配置的复杂度过高但安全提升不那么明显,对于有一定网络知识的用户也很折腾,不应该是推荐的最佳实践。所以我认为用户不必过于指望家用路由具有 v6 防火墙高级功能,但厂商把更多底层做成 UI 供高级用户选用,我并不反对。

    大众使用 SLAAC 、喜欢折腾使用 DHCPv6 的分法我觉得可能不太合适。喜欢折腾的人家里还是有不参与到折腾的人和设备,统一改成 DHCPv6 反而削弱了隐私扩展,更何况还有故意不支持 DHCPv6 的 Android 。如果家里没有这样的设备,全部都是服务端,那直接固定后缀应该就可以了。当然,这种场景一般会用企业级路由器,也超出了本帖的讨论范围。
    abc8678
        53
    abc8678  
       2022-02-16 00:41:40 +08:00 via Android
    求助,我刚开通 ipv6 访问,就源源不断有人尝试登录,消息都爆满了。有没有办法在 OpenWrt 路由器阻止外部访问,需要时远程开启?我有 zerotier 和向日葵。之前一直用 zerotier 连接 nas ,速度被压低了,或者穿透失败 有时屡试屡败,还是直接访问比较舒服。但我不是一直需要用,想用完就关。路由器 iptables 还没学会。关了入站数据,发现在外面还可以访问。关了转发数据,失联了。剩下个出站数据不敢改了。
    LnTrx
        54
    LnTrx  
    OP
       2022-02-16 18:19:17 +08:00
    @abc8678 我的群晖自从没了公网 IPv4 以后,仅有公网 IPv6 就没出过什么日志。看了下你发的其他帖子,还是建议去调查你 NAS 的地址是怎么被捅出去的。否则要么惶惶不可终日,要么使用非常不便,难以兼顾。
    abc8678
        55
    abc8678  
       2022-02-17 17:52:43 +08:00 via Android
    @LnTrx nas 的哪个地址? mac 地址?
    LnTrx
        56
    LnTrx  
    OP
       2022-02-17 23:24:53 +08:00
    @abc8678 “手中的设备的 IPv6 地址” “是 ipv4 在访问我。我明明没有 ipv4 的公网”
    cwek
        57
    cwek  
       2022-02-18 20:27:01 +08:00
    @LnTrx 我认为物联网设备优先分配 ULA ,然后通过 NPTv6 做前缀转换 NAT ,由边界路由器做这些物联网的安全网关。
    LnTrx
        58
    LnTrx  
    OP
       2022-02-18 23:49:57 +08:00
    @cwek 我觉得这样可能不太好,会增加物联网设备跨子网联动的复杂度和延迟
    cwek
        59
    cwek  
       2022-02-19 08:44:38 +08:00
    @LnTrx 延迟影响不大,因为只是前缀转换。不过连通性影响的话,要看设备是否需要对外,通过前缀区分内外,只要对外连接,被锤是迟早的事。
    LnTrx
        60
    LnTrx  
    OP
       2022-02-19 13:25:52 +08:00
    @cwek 如果需要第三方借助打洞、或者不停包发保活,想做到低能耗低延时是困难的。对外连接总是有风险,但我前面也论述了,IPV6 下外网直连的攻击面会小很多,相比之下设备自身的风险更加凸显。我还不是太理解你的方案,增加了前缀转换的步骤,能提供什么防火墙给不了的功能?
    cwek
        61
    cwek  
       2022-02-19 20:45:47 +08:00
    @LnTrx 前缀转换,实际相当于 1:1 NAT (而且可以不是 NPAT ),不需要保存会话,然后给网内给 ULA ,ULA 不全局路由,相当于内网,需要对外的话就是放开对应主机号的前缀转换,一切基本和以前 NAT 状态一样,对得外自然自己解决防火墙问题,路由器还是路由器,NAT 机制相对地弱化。
    LnTrx
        62
    LnTrx  
    OP
       2022-02-19 20:47:53 +08:00
    @cwek 还是没看出来,这相比公网 IPv6+防火墙的方案有什么额外的好处?
    fastcache
        63
    fastcache  
       2022-03-24 16:21:09 +08:00
    @ppbaozi 请教下
    1 ) IPv6 前缀会变,怎样全局放行?
    2 )哪里看群晖 DS 打开的端口?
    xPKK1qofAr6RR09O
        64
    xPKK1qofAr6RR09O  
       2022-03-25 12:16:43 +08:00
    @fastcache
    1.不指定原地址和目的地址的端口放行,需要软路由,ros 之类高阶一点的路由
    2.群晖的端口具体的服务具体去看就完事,bt 默认会开 upup ,在路由里也能看到
    Cyberpower
        65
    Cyberpower  
       2024-04-04 21:29:50 +08:00
    遇到了同样的问题,请问 op 最后解决了吗,网件没有防火墙设置功能。
    polaris1815
        66
    polaris1815  
       299 天前
    @loopinfor 可以的 你的 bt pt 平台都是知道你的地址的
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5878 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 32ms UTC 08:39 PVG 16:39 LAX 01:39 JFK 04:39
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86