Why does kdeconnect listen on port 1716/tcp all the time? How to close the port / secure it?

Question

Zenmap shows me that port 1716/tcp is open and sudo fuser -v 1716/tcp tells me kdeconnectd is responsible for it.

Why does kdeconnectd have the 1716 port opened all the time? And what would be best practice from a security standpoint for it? I'd like to use KDE Connect but not be vulnerable to any kind of attack that could exploit this open port.

Would that be having it closed except when I want to explicitly use KDE Connect maybe? If that would be a good thing to do: how can I do that?

I'm running Debian 9.1 with KDE and am still new to GNU/Linux.

Edit: based on schweik's answer a current way seems to be running sudo chmod -x /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd && pkill kdeconnectd (after running KDE Connect) and sudo chmod +x /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd before running KDE Connect. It has to be run again after updating the package and one might also move the file. Check with sudo lsof -i.

Solution 1

It sounds like UFW is probably what you're looking for. Several GUIs are available: http://linuxbsdos.com/2011/07/22/3-graphical-clients-for-managing-the-uncomplicated-firewall/

In a nutshell, one would add a rule to block port 1716 (both), leave it enabled most of the time, and disable it when you want to restore connectivity.

Beyond that, if someone was motivated or paid to work on it, it is technically possible to add custom port-knocking to both kdeconnect-android and your system firewall. On the Android side, basically one could configure something like "if port 1716 isn't open on the paired host, then try connecting to ports x, y, and z, in that order". This is like a combination on a combination lock, and the system firewall would need to be configured to open port 1716 when a device "knocks" on ports x, y, and z. The choice of ports would need to be random, and the "code" would need to be entered into both devices at the time of pairing... It would be kind a PITA for many users.

I imagine that the next step would be to integrate configuration of such "firewall combination" into the system settings of a desktop environment, similarly to how Bluetooth PINs are handled now.

Solution 2

Well, there is lot of garbage on fresh installed debian. Lot of them coud be swithched off, some can be configured to be more quiet, few can be uninstalled safelly, but I didnot find any cofigurable item, for disabling the Kdeconnect daemon. No changes in standard configuration files (e.g. /etc/xdg/autostart/kdeconnect.desktop) had any effect even if they were erased. Some gurus advice to disable the kdeconnect in the KDE/Plasma control panel (Autostart), but I cannot click it out while there is no kdeconnect item in the Autostart list.

I tried to (apt-get) purge the package, but due to (mystifying) dependeces nearly the half of KDE/Plasma packages was asked to be purged, too.

Finally I did it by the the cruelest unix way: I found the bin file of kdeconnect (/usr/lib/x86_64-linux-gnu/libexec/kdeconnectd) and set its excecute attribute off. Of course, this produce some error messages in the Plasma log, but the goal - silent the network - is reached.

Solution 3

That's because on desktop machines, KDE Connect works as a server, and phone apps are connecting to it. This shouldn't really be an issue, as all the incoming connections are being authenticated first (you have to “accept pairing” from a device in order for it to be able to do anything with your PC), but if you want, you can disable the kdeconnectd service (on KDE it is System Settings → Startup and Shutdown → Service Manager → Startup Services → uncheck “KDE Connect”; similar on other desktops) and run it manually when you need it.

Comments

[mYnDstrEAm]

I'm using iptables now as GUFW / UFW isn't working properly when blocking outbound traffic and have all ports closed by default. Whenever I use KDE Connect I'm temporarily opening the ports. I really like your idea of port-knocking combinations as authentication for executing firewall-changes. One could also associate specific iptables rules with specific programs (KDE Connect) so that they're allowed to make specific temporary preconfigured firewall changes (at startup and shutdown) without requiring root. Such program-rules-associations could be managed in an app or KDE and shared online.

[mYnDstrEAm]

I don't get why it listens all the time: it doesn't have to, it could just listen when I start it and also never get started without me explicitly starting it. I don't have an entry for KDE Connect in System Settings -> Startup and Shutodwn -> Background Services, do you?

[Lonnie Best]

@mYnDstrEAm : In Kubuntu 19.10, I too do not see a place to turn off KDE Connect. Here's of screenshot of what I do see, when trying to follow this answer's instructions: view screenshot.

[Lonnie Best]

Blocking that port on the firewall is fine, but (more fundamentally) how can you prevent the KDE Connect service from even listening on that port?

[AlexBrand]

"This really shouldn't be an issue" .... until a vulnerability is discovered in the authentication code.

[whtyger]

@deltaray Right you are: kde.org/info/security/advisory-20201002-1.txt