1

When doing some network security checks (on which I am an amateur) for my office PC, I discovered a few unknown tcp6 connections (with netstat -nt):

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
... (omitted known connections)
tcp6       0      0 aaa.bbb.ccc.ddd:1716      aaa.bbb.ccc.eee:55714     ESTABLISHED
tcp6       0      0 aaa.bbb.ccc.ddd:60810     aaa.bbb.ccc.fff:1716      ESTABLISHED

where aaa.bbb.ccc.ddd is my own ip. The other two unknown ip do come from the same subnet, but I have no idea why these connections are opened.

Questions:

  1. Where can I find the logs for these connections, e.g., who initialized the connections and how they are allowed/authorized (if this is the right word)?

  2. Is this a sign of network attack? Since I don't remember using any service that would need a tcp connection from the same subnet. Also, I have rebooted several times and these connections always seem to pop up automatically.

  3. If this indicates any possible insecurity, what should I do?

Update: As per the suggestion of @larsks and@ NikitaKipriyanov, I found that these connections are established by kdeconnect, which scans for available devices to pair in a local network. But it merely maintains such a list without actually pairing, so there shouldn't be any security issues at this point.

trisct
  • 113
  • 5
  • Use `netstat -lnpt`. That way you'll see the PID and the process name that holds the socket. Also, netstat is phased out gradually in Linux as do other old network tools; the replacement tool is `ss`. – Nikita Kipriyanov Oct 19 '22 at 03:20
  • @NikitaKipriyanov Thanks for the suggestion, `sudo netstat -tnp` shows the unknown connection is associated with "kdeconnect". But I have no idea how that is opened. – trisct Oct 19 '22 at 04:56
  • Now you learn [what kdeconnect is](https://kdeconnect.kde.org/), what it does and [why it uses network connections](https://unix.stackexchange.com/questions/384306/why-does-kdeconnect-listen-on-port-1716-tcp-all-the-time-how-to-close-the-port). And decide whether you need it or not. That's certainly end user question, offtopic on ServerFault. – Nikita Kipriyanov Oct 19 '22 at 08:15
  • @NikitaKipriyanov But perhaps learning how to find out the process associated with TCP connections should be on-topic? – trisct Oct 19 '22 at 08:40
  • Here's a [list of on-topics](https://serverfault.com/help/on-topic), if you interested. – Nikita Kipriyanov Oct 19 '22 at 09:13

1 Answers1

1

Where can I find the logs for these connections, e.g., who initialized the connections and how they are allowed/authorized (if this is the right word)?

There isn't really a general answer to this question.

Logging of this sort of information is up to specific applications (e.g., for a web server you would probably have some sort of access log, while something like ssh will by default log to the system log).

Is this a sign of network attack?

There's not enough information here to make that determination. Consider running sudo netstat -tnp (the -p will show the process associated with each connection; the sudo is necessary in order to see processes that aren't owner by your current user).

If you have questions about the output of this command, update your question to include the output.

If this indicates any possible insecurity, what should I do?

The general response to a compromise is (a) determine what permitted the ingress, then (b) erase and reinstall the system and (c) ensure the new configuration does not permit the same method of access.

But as I said earlier, at this point there's not enough information to figure out if this is something to worry about or not.

larsks
  • 43,623
  • 14
  • 121
  • 180
  • Thanks for the suggestion, `sudo netstat -tnp` shows the unknown connection is associated with "kdeconnect". But I have no idea how that is opened. – trisct Oct 19 '22 at 04:56