Restic background communication over TCP

Hello all,

I’ve spend some time to create an understanding in the “restic” background network communication.

Wenn I start and “restic backup”, restic opens two TCP connections:

  • < Domain Controller >:135 (Port = 135)
  • < Domain Controller >:49158 (Port = 49158)

The connections will be established with restic start and closed after backup ends or restic is stopped.

Does anyone knows more details about this connections?
Why does restic opens this connections and is there a way to avoid this behavior?

I use restic on Windows 64bit on a local drive, no cloud storage or something involved. No restic update or so.

many thanks,
Jo

Uh, hm. Interesting. It’s not something we’ve deliberately built into restic, so I guess that either the connections are done automatically by the Windows environment, or the Go standard library does them in the background, e.g. for looking up the user name for a given user ID.

Almost certainly that is not restic opening those ports, if you are backing up to a local repository. (Especially port 135 – that is a low port, probably some Windows service is using that.)

135 is for DCOM, which Windows uses for various things.

I check the connections with Sysinternal ProcessExplorer on a system in an active directory environment.

@matt the fully connection looks like:
TCP, 192.168.42.1:55928 --> Domain Controller 192.168.1.1:135 and
TCP, 192.168.42.1:55929 --> Domain Controller 192.168.1.1:49158
and restic makes this connections exactly during backup is running. So the lower ports used on the domain controller and not on the local machine.

@cdhowie good to know, I found similar information, this makes sense because I use restic in an environment where an active directory is running. But why does the domain controller to know, that I will run an restic backup? If I run restic on many servers does this have any negative side effects?

@fd0 Do you have an idea how stop all remote connection in restic?

BTW: I found many http urls embedded to restic, may this part of the GO standard library or some libs but there many urls which are not related to any restic possible backup destination. Does anyone checked this?

Regarding my motivation of this questions: I entrust my data to restic and I want to make sure that the data does not somehow flow off or disappear due to a faulty operation on my side. :wink:
Restic is exact what I’m looking for since years for my Windows Backups. Good job. :+1:

Of course there are URLs in the binary, and of course destinations aren’t hard-coded (otherwise, destinations would not be configurable). Why don’t you provide some more information – like what are the URLs you found that you have questions about?

And you can look yourself, you know – restic and Go are both open source: GitHub - restic/restic: Fast, secure, efficient backup program and GitHub - golang/go: The Go programming language

What makes you think that restic is telling the domain controller about anything? More likely, some information is being looked up in the domain, such as metadata about users who own files that are being backed up (though this is speculation on my part).

1 Like

Hi @matt,

the URL I tried to find in the restic and golang repository are

https://slack.com/identifier
https://id.twitch.tv/
https://oauth.vk.com/
https://api.patreon.com/
https://api.soundcloud.com/
https://connect.stripe.com/
https://www.googleapis.com/

but I was not successful. Do you know if there are some go libs which restic uses, have this URLs included?

thanks,
Jo

These seem to be from the OAuth2 go package. They were removed from OAuth2 in January and thereby from restic on the last dependency update.

2 Likes

Hi @cdhowie,

I do not see a problem, but I’m wondering what is going on. When I use restic in a wider area I wan’t to understand the IO traffic, which is initiated by restic. And I want to avoid an “ticket” from the security team, when restic is connecting the domain controller from every server or pc, when I run it automatically. That’s all.

many thanks,
Jo

The only indication of this is that it happens at the same time. You’ve provided no evidence this is actually the case, especially considering that there is some indication the machine and ports involved are used by the Windows operating system.

Hello @Odin, may you are right. I used the Sysinternals Process Explorer and under Properties and the tab “TCP/IP” these connections are listed. I believed in Process Explorer that he assigning connection to process right. But may in some circumstances this is not right, may restic and golang uses an Windows LIB which makes this connections.

Guys, the source is there for you to read – if you are concerned, just look at the source code. If you don’t know how to read it, but are so curious, then learn how. It is well worth your time!

@matt not a very constructive answer. But I understand you don’t know either. Being able to program GO and do a code review are “two pair of boots”.

Where is your repository is it on cifs shares that is authenticated by the windows user? Then this traffic that you see may make genuine sense. But still don’t be sure till u have diagnosted.

You can try by using rclone as a backend to your repro with restricted eg restricted - r rclone:myrepro

Try transfering some small dummy files to the repro with rclone and see if you see something similar with rclone.

1 Like

No, I just trust restic (because I’m familiar with its code by having read some of it, even though I didn’t write it). If you are suspicious about what restic is doing and no one else is able to give you a good answer in the forums, then you can always look yourself and figure it out.

And even if I did say, “I’ve not seen anything in restic to support these claims” (which is true), that won’t be satisfying to the asker. If you want to know, I guess you just have to take the time and look yourself (this is basically asking for a free audit).