15

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.

Improve this question

4 Answers 4

Reset to default
5

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.

Improve this answer
2
  • 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
    Commented Jun 25, 2018 at 12:55
  • 1
    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?
    – Lonnie Best
    Commented Apr 6, 2020 at 6:48
5

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.

Improve this answer
1
  • 2
    The dependency issue may be solved on never Debian versions. On my Kubuntu 22.04, sudo apt autoremove kdeconnect doesn't remove anything unnesessary
    – Expurple
    Commented Sep 7, 2022 at 9:33
2

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.

Improve this answer
5
  • 2
    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?
    – mYnDstrEAm
    Commented Jun 15, 2019 at 9:43
  • 3
    @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
    Commented Apr 6, 2020 at 6:41
  • 3
    "This really shouldn't be an issue" .... until a vulnerability is discovered in the authentication code.
    – deltaray
    Commented Jul 9, 2021 at 20:47
  • 5
    @deltaray Right you are: kde.org/info/security/advisory-20201002-1.txt
    – whtyger
    Commented Jan 28, 2022 at 12:01
  • @whtyger From that advisory: "so the brute force approach is to uninstall the kdeconnect package"
    – Kai Petzke
    Commented Dec 8, 2022 at 15:48
0

kdeconnectd allows people to remote control their desktop computer from their smartphone. While there are definitely use cases for this, it is also a security risk, because it requires an open port, that people can connect to. The security issues start by gossiping around: "Hey, I am a linux box running KDE" in the public WiFi of your local Starbucks or your long distance airport, and go on to a Denial of Service security hole, and maybe more:

https://kde.org/info/security/advisory-20201002-1.txt

So, the best action is to follow the advice of the KDE team themselves: "the brute force approach is to uninstall the kdeconnect package".

Improve this answer

You must log in to answer this question.

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