"Anonymous" data sent to Microsoft ?

[Mart124]

Hi,

Using tcpdump, I noticed that self-hosted installation sends data to 40.77.226.250:443, which has a SSL certificate for *.vortex.data.microsoft.com.
Do the docker images send so called "anonymous" data to Microsoft ?
Could this be disabled ?

Thank you !

[kspearrin]

When do you see it happening? Perhaps it is part of the .NET Core CLI telemetry mentioned here? https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

Try setting environment variable DOTNET_CLI_TELEMETRY_OPTOUT to 1 and see if it stops.

[Mart124]

When I browse a vault (using the web vault for instance), it may take some minutes, but discussion with *.vortex.data.microsoft.com will start.

I then set the following for each Docker service in docker/docker-compose.yml file :

    environment:
      - DOTNET_CLI_TELEMETRY_OPTOUT=1

Unfortunately it does not help.

export DOTNET_CLI_TELEMETRY_OPTOUT=1 in bitwarden.sh, and restarting the whole application does not help either.

[kspearrin]

Hmm. Maybe it is Application Insights trying to send telemetry data? I was under the impression that it would not "light up" without something like an Azure environment triggering it. Maybe I'm wrong though dotnet/aspnetcore#2051

Unfortunately it seems we have to set a runtime disabled flag so I don't think you can check that without us providing a new build (which we can do next version). One comment suggests a ASPNETCORE_preventHostingStartup=True environment variable might disable it though.

How are you testing/seeing this from the host machine? If you can swing by our dev chatroom sometime I can try to send you a few custom builds to debug this further. https://gitter.im/bitwarden/Lobby

[Mart124]

So, I tried to set env var ASPNETCORE_preventHostingStartup=True, as above, for each Docker service in docker/docker-compose.yml, but it did not help.

According to this, Application Insights are enabled with production environment.
I then set ASPNETCORE_ENVIRONMENT=Development in docker/global.env (and restarted the app, of course). Did not help either.

According to this and this, ASPNETCORE_preventHostingStartup=True should be set in the launchSettings.json files, a modification as you stated I can't do myself (but could be done in next version, good news 👍).

Btw, we could then wonder if ASPNETCORE_ENVIRONMENT in docker/global.env has any effect, as it's already set in launchSettings.json files (and ASPNETCORE_preventHostingStartup in docker/global.env has no effect).

According to this, there could be another solution, which is to set TelemetryConfiguration.DisableTelemetry=true in Startup.Configure(). Of course this also needs to rebuild the app.

And a third one, directly in Visual Studio. I'm not sure however if this solution will modify projects files, or if it's a "local" setting only (which everyone working on the project would have to manually tick also).

How are you testing/seeing this from the host machine?

On a Linux server.
Let's assume you're accessing the vault from IP 1.2.3.4.
Your server public network interface is eth0 (ifconfig -a or ip addr show to show all interfaces).
Then you can do, on the server :
tcpdump -i eth0 -n port 443 and host not 1.2.3.4

[kspearrin]

I'm trying to reproduce this on my end with tcpdump but am getting a lot of noise and haven't been able to spot the IP you listed yet. How often does it occur while using the web vault?

[Mart124]

I run ./bitwarden.sh start, login, browse / refresh an organization vault and a user vault several times, and then communication starts. This is how I can reproduce the issue each time.

[kspearrin]

Issue has been opened with mssql team: microsoft/mssql-docker#312

[gt2416]

Any solution to this on the user's end ? Its a shocking amount of times it tries to send back data, more than my Windows server machine :/ This is while Bitwarden isnt being used.

[milosvvv]

I just noticed this happening while looking through docker debug logs:

Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] query vortex.data.microsoft.com. (A) from 172.19.0.5:36313, forwarding to udp:thednserver"

Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] received A record "65.55.44.109" for "bn2.vortex.data.microsoft.com.akadns.net." from udp:thednserver"
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="Name To resolve: vortex.data.microsoft.com."
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] query vortex.data.microsoft.com. (A) from 172.19.0.5:53857, forwarding to udp:thednserver"
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] received A record "65.55.44.109" for "bn2.vortex.data.microsoft.com.akadns.net." from udp:thednserver"
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="Name To resolve: vortex.data.microsoft.com."
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] query vortex.data.microsoft.com. (A) from 172.19.0.5:46163, forwarding to udp:thednserver"
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] received A record "65.55.44.109" for "bn2.vortex.data.microsoft.com.akadns.net." from udp:thednserver"
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="Name To resolve: vortex.data.microsoft.com."
Nov 18 09:08:48 thebitwardenserver docker.dockerd[21925]: time="2019-11-18T09:08:48" level=debug msg="[resolver] query vortex.data.microsoft.com. (A) from 172.19.0.5:37205, forwarding to udp:thednserver"

I've since manually blocked the domain resolving in /etc/hosts as provided in #293

[Mart124]

Strangely enough @kspearrin #293 seems to have no (more) effect at all !
Looking at /etc/hosts file in mssql containers, it does not contain the blackhole hard-coded entries...
Any issue ?

[Mart124]

OK, here's a workaround, in docker-compose.override.yml :

services:
  mssql:
    extra_hosts:
      - "settings-win.data.microsoft.com:127.0.0.1"
      - "vortex.data.microsoft.com:127.0.0.1"

@kspearrin I think you could put this directly into docker-compose.yml and revert #293,
which has finally moved here :

server/util/MsSql/Dockerfile

Lines 21 to 23 in 5d047d5

	# As the setting above does not work, let's use the workaround below
	RUN echo 127.0.0.1 settings-win.data.microsoft.com >> /etc/hosts
	RUN echo 127.0.0.1 vortex.data.microsoft.com >> /etc/hosts

[Mart124]

I also think that mssql container, as certainly some others, don't need a public network access.
They should only be able to communicate with the other containers.
Reminds me @silverwind idea : #495 (comment)

[kspearrin]

Correct. The database container doesn't need any outside network connectivity.

[Mart124]

The proper approach I think is then to deny public network by default.

So, in docker-compose.yml :

networks:
  default:
    internal: true
  public:
    internal: false

And for services needing public network, and only for them :

    networks:
      - default
      - public

@kspearrin, could we go for this please ?
Many thanks 👍

[kspearrin]

@Mart124 See c27b72e

You can test this on the dockerhub dev tag if you like.

[Mart124]

Many thanks @kspearrin, let's give this a try 👍
By curiosity, don't you prefer the above method, to configure default network as internal, and only give public access to services needing it ?
I'm surprised 7 containers out of 10 need public access ? I would have though most of the traffic would have gone through the nginx service...
Thank you again !

[Mart124]

In addition, unfortunately, your commit does not work.
The 3 services assigned to the private network can't communicate with the other services, as they are isolated in their own private network.
I think you should rather do like above (#286 (comment)), making the default network as private, and adding a public network to the services needing it.

[kspearrin]

@Mart124 Try fe3378b whenever it finishes building.

[Mart124]

Yes, like this it works @kspearrin 👍
Perfect, sounds good !
I think you can now revert the following which is useless :

server/util/MsSql/Dockerfile

Lines 21 to 23 in 5d047d5

	# As the setting above does not work, let's use the workaround below
	RUN echo 127.0.0.1 settings-win.data.microsoft.com >> /etc/hosts
	RUN echo 127.0.0.1 vortex.data.microsoft.com >> /etc/hosts

Edit : see PR #598 for this.

[netstat-peanut]

Is there a tl;dr posted somewhere covering why BW uses mssql in favor of the alternatives? I'm sure it exists, as I can't be the only person put off by it.