clo*_*ney 6 networking security debian port wireguard
操作系统:Debian 12
我经常从事 OPSEC 工作,因为安全对我来说非常重要。现在我有一个新的路由器,当我插入 LAN 电缆时,它会在我的计算机上打开一个端口。当我断开 LAN 电缆时,该端口被关闭。我的路由器上没有配置端口转发
未插入 LAN:
$ sudo ss -lntup
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=5))
tcp LISTEN 0 32 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=6))
Run Code Online (Sandbox Code Playgroud)
局域网已插入:
$ sudo ss -lntup
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=5))
udp UNCONN 0 0 0.0.0.0:33955 0.0.0.0:*
tcp LISTEN 0 32 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=6))
Run Code Online (Sandbox Code Playgroud)
当我重新插入 LAN 时,它会打开另一个端口:
$ sudo ss -lntup
udp UNCONN 0 0 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=5))
tcp LISTEN 0 32 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=2717,fd=6))
udp UNCONN 0 0 0.0.0.0:49258 0.0.0.0:*
Run Code Online (Sandbox Code Playgroud)
这是什么原因造成的?我不认为这是正常行为。尽管状态为 UNCONN,但这似乎存在安全风险,因为该端口是由我的 LAN 电缆打开的,对吧?我用的是WireGuard。当我禁用它时,unconn 套接字消失了。
为什么要这样做?
我怎样才能防止这种情况发生?
A.B*_*A.B 20
来自OP的评论:
@AB 是的,我使用 wg。当我禁用 wg 时,unconn 套接字消失了。为什么wg要这么做?
看来系统被配置为每当主接口有链路(载波检测)时就带来 WireGuard(隧道)接口。
WireGuard 需要 UDP 套接字才能与对等方通信。wireguard.ko对于内核实现(内核模块,例如ip link add wg0 up type wireguard:)或用户空间实现(例如:wireguard-go wg0+ )都是如此ip link set wg0 up。
如果 WireGuard 配置未指定本地端口,则会随机动态选择。“客户端”WireGuard 接口通常就是这种情况(即使 WireGuard 遵循点对点模型):通常是没有稳定公共地址并且在存在隧道之前无法到达的一侧。
要确认此 UDP 端口与动态 WireGuard 配置之间的关系,只需运行wg。即使对于完全未配置的界面,它至少会显示如下内容:
interface: wg0
listening port: 36387
Run Code Online (Sandbox Code Playgroud)
这将是接口处于 UP(内核实现)时或在所有情况下(如当前所见wireguard-go)所使用的端口。
当它由内核处理时,端口仅在接口启动时才会侦听。但如果端口发生变化,则意味着每次删除并重新创建接口(否则相同的端口将重新出现)。没有与套接字关联的进程信息,因为它是在内核中处理的。
UNCONN关于这意味着套接字处于未连接状态的注释。
未连接并不意味着存在错误或超时。这是在通信中使用 UDP 套接字的两种方法之一。它允许使用单个套接字以有效的方式与多个对等点进行通信。
两种 WireGuard 实现都在未连接模式下使用 UDP 套接字:至少对于用户空间来说,这意味着它不在该套接字上使用,而是connect(2)使用/进行通信(在另一个方向上同样如此)。sendmsg(2)send(2)write(2)recvmsg(2)