Score:1

Where does Ubuntu log TCP connections?

ru flag

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.

Nikita Kipriyanov avatar
za flag
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`.
trisct avatar
ru flag
@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.
Nikita Kipriyanov avatar
za flag
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.
trisct avatar
ru flag
@NikitaKipriyanov But perhaps learning how to find out the process associated with TCP connections should be on-topic?
Nikita Kipriyanov avatar
za flag
Here's a [list of on-topics](https://serverfault.com/help/on-topic), if you interested.
Score:1
pt flag

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.

trisct avatar
ru flag
Thanks for the suggestion, `sudo netstat -tnp` shows the unknown connection is associated with "kdeconnect". But I have no idea how that is opened.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.