6

OS: Debian 12

I'm working on my OPSEC pretty often because security is very important for me. Now I have a new router which opens a port on my computer when I plug in the LAN cable. When I disconnect the LAN cable, the port is closed. I have no port-forwarding configured on my router

No LAN plugged in:

$ 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))

LAN plugged in:

$ 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))

When I re-plugin my LAN, it opens another port:

$ 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:*

What causes this? I don't think this is normal behavior. Even though the state is UNCONN, it seems like a security risk because the port is opened by my LAN cable, right? I use WireGuard. When I disable it, the unconn socket is gone.

Why does it do this?

How can I prevent this from happening?

Improve this question
8
  • @A.B the UDP port 53 is not "from the kernel", see the process owner column. The 49258 might be, but it's really just an unconnected UDP socket; these can remain if you remove a network interface. Commented Dec 15, 2023 at 20:22
  • 3
    @MarcusMüller I'm talking about ports 33955 and 49258 : no dnsmasq Commented Dec 15, 2023 at 20:22
  • as said, that's an UNCONN socket, which can remain after a socket disappeared. Doubt you'll find out anything that way. Commented Dec 15, 2023 at 20:27
  • @MarcusMüller want an unconn socket? socat -u udp4-recv:5555 - ? Want to hide the process from ss? I'm leaving it as an exercise. Commented Dec 15, 2023 at 20:30
  • @A.B Yes I use wg. When I disable wg the unconn socket is gone. Why wg does this? or its something wg related? Could you please create an answer in where you clarify this a bit. I love to learn and I will accept the answer as correct. I also see you're in to nftables. If you like a challenge, I asked something complicated about nftables 10 days ago, you can check my account :) Commented Dec 15, 2023 at 20:50

2 Answers 2

Reset to default
20

From OP's comment:

@A.B Yes I use wg. When I disable wg the unconn socket is gone. Why wg does this?

It appears the system is configured to bring a WireGuard (tunnel) interface whenever the main interface has a link (carrier detect).

WireGuard requires an UDP socket to communicate with the peer. That's true both for the kernel implementation (kernel module wireguard.ko, eg: ip link add wg0 up type wireguard) or the userspace implemetation (eg: wireguard-go wg0 + ip link set wg0 up).

If the WireGuard configuration doesn't specify the local port, it's chosen dynamically at random. That's often the case for a "client" WireGuard interface (even if WireGuard is following a peer-to-peer model): usually the side which doesn't have a stable public address and can't be reached before there's a tunnel.

To confirm the relation between this UDP port and the dynamic WireGuard configuration, just run wg. Even for a completely unconfigured interface it will at least display something like:

interface: wg0 listening port: 36387

which will be the port used when the interface is UP (kernel implementation), or in all cases (as currently seen with wireguard-go).

When it's handled by the kernel, the port is listening only when the interface is up. But if the port changes, that means each time the interface was deleted and recreated (else the same port would reappear). There's no process information associated to the socket because it's handled in kernel.

Notes about UNCONN which means socket in unconnected state.

Unconnected doesn't mean there's an error or a timeout. It's one of the two ways to use UDP sockets in communication. It allows to use a single socket to communicate with multiple peers in an efficient way.

Both WireGuard implementations use an UDP socket in unconnected mode: at least for userspace that means it doesn't use connect(2) on this socket and communicates using sendmsg(2) rather than send(2)/write(2) (and likewise recvmsg(2) etc. in the other direction).

Improve this answer
0
1

Actually the "cable" cannot open a port (that's what the question seems to assume); only software can open ports. Today's computer systems are fairly complex, but not "magic".

I suspect on the machine there is one process waiting for new interfaces to come up (e.g. I know that ntpd does that). Plugging in the cable effectively makes an interface to go up, which in turn will signal the software process (via kernel interface) that the interface went up, and the process will finally open the port.

Maybe see https://stackoverflow.com/a/24207967.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.