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?

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. Dec 15, 2023 at 20:22
  • 3
    @MarcusMüller I'm talking about ports 33955 and 49258 : no dnsmasq
    – A.B
    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. 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.
    – A.B
    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 :)
    – clooney
    Dec 15, 2023 at 20:50

2 Answers 2

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .