Why does gitea silently connect to some IP addresses on the network like a Trojan in the background? can the author explain this situation?

[VeniVidiVici9]

Why does gitea silently connect to some IP addresses on the network like a Trojan in the background? can the author explain this situation?

I also encountered a situation similar to illegal login, I don’t know if this is an illegal login, but there are information such as "/user/login" and "/user/login 200 OK" in the log. Is this an illegal login? This let people feel uneasy. can the author explain this situation?

it's always like this at 5 o'clock every morning, and my firewall keeps alarming. 182.254.52.17 / 61.241.50.63 / 14.18.182.223 is not my IP address. What do these IP address use to do? It always connect these addresses silently in the background.

such as belowing log:

[Macaron] 2020-03-31 01:55:33: Started GET /user/avatar/VeniVidiVici6/-1 for 182.254.52.17
[Macaron] 2020-03-31 01:55:34: Completed GET /user/avatar/VeniVidiVici6/-1 302 Found in 645.9542ms
[Macaron] 2020-03-31 05:00:34: Started GET /user/login for 182.254.52.17
[Macaron] 2020-03-31 05:00:35: Completed GET /user/login 200 OK in 576.741898ms
[Macaron] 2020-03-31 09:08:15: Started GET /vendor/assets/roboto-fonts/roboto-v20-latin-ext_cyrillic-ext_latin_greek_vietnamese_cyrillic_greek-ext-700.woff2 for 61.241.50.63
[Macaron] [Static] Serving /vendor/assets/roboto-fonts/roboto-v20-latin-ext_cyrillic-ext_latin_greek_vietnamese_cyrillic_greek-ext-700.woff2
[Macaron] 2020-03-31 09:08:18: Completed GET /vendor/assets/roboto-fonts/roboto-v20-latin-ext_cyrillic-ext_latin_greek_vietnamese_cyrillic_greek-ext-700.woff2 200 OK in 2.894195509s
[Macaron] 2020-03-31 11:30:55: Started GET /user/login for 14.18.182.223
[Macaron] 2020-03-31 11:30:55: Completed GET /user/login 200 OK in 501.081188ms

I use a docker container, not a binary file, and the version number is: 1.12.0 + dev-69-g972b3bf3b. image checksum is sha256:c4a654eb05c032eac9ee57de853c725de6169f93f0a45ccd506c7bf4bed03fe5

I have compared the information in the build log. The checksum is the same on the Docker Hub official website server.

Docker Hub official website server address is https://hub.docker.com, Checksum on Docker Hub official website server is： gitea/gitea:latest Digest:sha256:c4a654eb05c032eac9ee57de853c725de6169f93f0a45ccd506c7bf4bed03fe5 OS/ARCH linux/arm64/v8 Size 48.2 MB Last pushed 12 hours ago by giteabot

the following is my build image log:

1 docker image building is started ...
2 [ fetch stage begin.]
3 fetch dockerfile and context
4 Note: checking out 'origin/master'.
5
6 You are in 'detached HEAD' state. You can look around, make experimental
7 changes and commit them, and you can discard any commits you make in this
8 state without impacting any branches by performing another checkout.
9
10 If you want to create a new branch to retain commits you create, you may
11 do so (now or later) by using -b with the checkout command again. Example:
12
13 git checkout -b <new-branch-name>
14
15 HEAD is now at 949a634 Create Dockerfile
16 [fetch successfully.]
17 ==========================================
18 [docker version.]
19 Client:
20 Version: 17.06.1-ce
21 API version: 1.30
22 Go version: go1.8.3
23 Git commit: 874a737
24 Built: Thu Aug 17 22:53:49 2017
25 OS/Arch: linux/amd64
26
27 Server:
28 Version: 17.06.1-ce
29 API version: 1.30 (minimum version 1.12)
30 Go version: go1.8.3
31 Git commit: 874a737
32 Built: Thu Aug 17 23:01:50 2017
33 OS/Arch: linux/amd64
34 Experimental: false
35 ==========================================
36 [docker build stage begin.]
37 Sending build context to Docker daemon 58.88kB
38 Step 1/2 : FROM docker.io/gitea/gitea:linux-arm64
39 linux-arm64: Pulling from gitea/gitea
40 8a0637ca1ac9: Already exists
41 7031fd05e75e: Pulling fs layer
42 65efb18789dc: Pulling fs layer
43 558e3fd7af38: Pulling fs layer
44 c832634f81a8: Pulling fs layer
45 0f60d3dbbbe7: Pulling fs layer
46 0f60d3dbbbe7: Download complete
47 558e3fd7af38: Download complete
48 65efb18789dc: Verifying Checksum
49 65efb18789dc: Download complete
50 7031fd05e75e: Verifying Checksum
51 7031fd05e75e: Download complete
52 7031fd05e75e: Pull complete
53 65efb18789dc: Pull complete
54 558e3fd7af38: Pull complete
55 c832634f81a8: Verifying Checksum
56 c832634f81a8: Download complete
57 c832634f81a8: Pull complete
58 0f60d3dbbbe7: Pull complete
59 Digest: sha256:c4a654eb05c032eac9ee57de853c725de6169f93f0a45ccd506c7bf4bed03fe5
60 Status: Downloaded newer image for gitea/gitea:linux-arm64
61 ---> 5fa53b357dc6
62 Step 2/2 : MAINTAINER aliyun <104561102@qq.com>
63 ---> Running in e16cb35406c2
64 ---> 787a295a8939
65 Removing intermediate container e16cb35406c2
66 Successfully built 787a295a8939
67 Successfully tagged registry.cn-shenzhen.aliyuncs.com/venividivici9/gitea:linux_64_2020-03-30
68 [ build successfully.]
69 ==========================================
70 [push stage begin.]
71 docker push registry.cn-shenzhen.aliyuncs.com/venividivici9/gitea:linux_64_2020-03-30
72 The push refers to a repository [registry.cn-shenzhen.aliyuncs.com/venividivici9/gitea]
73 7e93115402cd: Preparing
74 efc5185f294d: Preparing
75 a31c2199f0ce: Preparing
76 819b6c38d657: Preparing
77 90e0ea015c7c: Preparing
78 294ac687b5fc: Preparing
79 819b6c38d657: Pushed
80 a31c2199f0ce: Pushed
81 7e93115402cd: Pushed
82 294ac687b5fc: Pushed
83 90e0ea015c7c: Pushed
84 efc5185f294d: Pushed
85 linux_64_2020-03-30: digest: sha256:0b20f3abab8719e5be6848a0f0a591f69d2cd1201b9d3e857da9a826c65dacc1 size: 1575
86 [push successfully.]
87 {"exitCode":0, "message":"fetch build push successfully"}

By the way, how to upload screenshots in these Issues, I can’t upload the screenshots, and the description is not as vivid and real as the screenshot.

[VeniVidiVici9]

And these addresses are often connected by default in the background.

183.192.179.16 182.254.52.17 14.18.182.223 61.241.50.63 101.89.19.140 113.96.198.54 59.36.132.240 14.215.156.146

[lafriks]

Why open again such issue. Gitea itself will not connect to any services except what you have configured. So either user avatar federation, git mirroring, webhooks you or your users have configured or external authorizations services you have enabled. Please stop spamming Gitea issues, posting these IP addresses are useless.

[zeripath]

Do you have ENABLE_FEDERATED_AVATAR=True in your custom/conf/app.ini ? I suspect that this is from the libravatar service. I assume that these internal requests are related to accesses to Gitea - in particular the Avatars.

In terms of adding screenshots - that's Github - you should take a look at their pages.

[lafriks]

Logs you have shown is that not gitea service is connecting to these IP addresses but someone from that IP address is opening login form (not even trying to login as otherwise there would be POST request). These could be just random Chinese network scanners