Connection from unkown IP (internettl.org?)

[Endstille]

Hello everyone,

I'm new to OpenVPN but for now, everything is working exactly as it should. However; today i noticed something in the logs that's concerning me (see partial log below).

As you can see, the first and last line in the logs are from different timestamps than the lines inbetween them. These lines in the middle, however, are uknown to me:
*the IP address (America) is completely different from the ones i'm "used to" (Europe)
*no client-"names" are mentioned
*the link-mtu's and tun-mtu's match (that is never the case; haven't looked into it though but so far I've ignored it since noone has any trouble connecting/accessing shares)

This IP seems to be owned by "internettl.org", which mentions the following items on their website:
-->header
The InterneTTL is a research project that identifies servers on the Internet. InterneTTL continuously scans every host on the Internet providing IT and security teams with realtime visibility into active servers.

-->Scanning process
The InterneTTL project gathers data in two steps. During the first step involves scanning to determine which service ports are open and the second step involves connecting to the public facing service to identify what application is used.

InterneTTL IPs can be whitelisted or blacklisted at your preference.
IPs: 104.152.52.21-104.152.52.39
Domains: census[n].internettl.org.

-->Collected
An example of the data collected by the InterneTTL research project are x509 certificates on HTTPS we servers. This data is used by security teams to identify revoked certificates and possible malicious command and control servers.

-->Technical details
This research project is not related to any malicious activity. The data is collected to identify active servers on the Internet and usage of software of online services. The InterneTTL research project does at no point bypass any technical barrier or access non-public-facing online services.

I really don't know what I should think about this... Does anyone know more about this? Why are they able to "connect"?

Thanks in advance!

Endstille

*****LOG*****
Tue Feb 23 13:08:30 2021 TCP/UDP: Closing socket
Tue Feb 23 14:28:35 2021 MULTI: multi_create_instance called
Tue Feb 23 14:28:35 2021 Re-using SSL/TLS context
Tue Feb 23 14:28:35 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Feb 23 14:28:35 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Feb 23 14:28:35 2021 Control Channel MTU parms [ is this safe to share? ]
Tue Feb 23 14:28:35 2021 Data Channel MTU parms [ is this safe to share? ]
Tue Feb 23 14:28:35 2021 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-server'
Tue Feb 23 14:28:35 2021 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-client'
Tue Feb 23 14:28:35 2021 TCP connection established with [AF_INET]104.152.52.34:46699
Tue Feb 23 14:28:35 2021 Socket flags: TCP_NODELAY=1 succeeded
Tue Feb 23 14:28:35 2021 TCPv4_SERVER link local: (not bound)
Tue Feb 23 14:28:35 2021 TCPv4_SERVER link remote: [AF_INET]104.152.52.34:46699
Tue Feb 23 14:29:06 2021 104.152.52.34:46699 Connection reset, restarting [-1]
Tue Feb 23 14:29:06 2021 104.152.52.34:46699 SIGUSR1[soft,connection-reset] received, client-instance restarting
Tue Feb 23 14:29:06 2021 TCP/UDP: Closing socket
Tue Feb 23 15:20:12 2021 MULTI: multi_create_instance called

[TinCanTech]

Check this out: http://openvpn.net/howto.html#mitm

[Endstille]

Thank you for the redirection!

I added following lines to the .ovpn files:
to the server ovpn-file, I added:
remote-cert-tls client

to the client ovpn-file, I added:
remote-cert-tls server

Now i get following log messages on the server:
((user))/((public mobile ip address)) MULTI: bad source address from client [100.127.128.245], packet dropped

Am I correct to assume that these messages then mean: "man in the middle @ IP 100.127.128.245" --> blocked (since i only started getting them after adding the remote-cert-tls lines)

What i noticed now though, are following log messages on the client:
18:01:46.984 -- UNUSED OPTIONS
4 [resolv-retry] [infinite]
5 [nobind]
6 [persist-key]
7 [persist-tun]
11 [remote-cert-tls] [server]
15 [verb] [5]

The server seems to validate the client but how can I make sure the client validates the server (since option #11 seems to be unused)

Another question I would like to ask is, what info is readable for the "middleman" or how do I make sure I didn't take anything in from a man-in-the-middle attack or do I now assume everything is invalidated (my PKI & my Windows password) and restart or do I not care (since every single password is 20+ chars long, has no logic in them, are only stored on physical paper, are not exchanged (since DH-"exchange" & CA.key certification) and it's just a home-server project (not such important files)? Could someone also explain what these "middlemen" are trying to do though, since I thought all traffic was encrypted with OpenVPN (not worth trying?)?

I'm asking/going to ask a lot of questions so i'm sorry in advance - i only took up a sys-/netadmin course this year, so much new things to learn and I'm having some difficulties really understanding everything about OpenVPN/finding relevant info for what i'm trying to do:
*like making ccd files --> is it just a notepad-file that has the common name of the client and a ".conf"-extension?
*or knowing where to place these files --> /etc/openvpn/... for linux however, i'm hosting OpenVPN on windows (does it matter as long as the path is specified in the server-ovpn file?)
*is there any specific item/rule/file i can specify to make access harder; e.g. i now have 6 files for each client ca.crt, dh.pem (+-3000bits), ta.key, ((client)).crt, ((client)).key & ((client)).ovpn) - can I add another file to specify in the ovpn file to make authentication more reliable/consistent/less accessible for non-authorized users?

Thank you for your time/answers!

Endstille

[TinCanTech]

Now check this out: https://openvpn.net/community-resources ... n-security

[Endstille]

Thank you, that (ta.key) is already configured (not the linux parts though, since i'm using windows); however port scans are the reason i moved from port 443 to another port (yesterday). Today i looked for more port scans but didn't notice any on the new port but did notice that weird connection-establishement that I mentioned in the first post (once).

[TinCanTech]

that (ta.key) is already configured (not the linux parts though, since i'm using windows); however port scans are the reason i moved from port 443 to another port (yesterday).

Are you saying that with a --tls-auth key the scanner was still able to raise a TCP session on your server ?

If so then that sounds like a howler of a bug ..

[Endstille]

I think so,

the server-ovpn file contains this line/rule:
tls-auth "C:/Program Files/OpenVPN/easy-rsa/ta.key" 0
#with "-signs since path contains spaces

and the client-ovpn file contains this line/rule:
tls-auth ta.key 1

I've verified the files are placed in the correct folder (which they are).

The port scans i got yesterday (on port 443) were only logged (bouned off/no connection) but this specific connection on the new port (from 104.152.52.34:46699 - which is outside of our region/a foreign IP) was established with these (above mentioned) rules configured.

Since so much info was left out of the log/such a big part of the connection did not get established (client name, virtual private IP address assignment,...) it might be a bug, I just don't know enough about networking/security (yet) to verify/know what is and what isn't possible.

So, for now, the only thing i've changed is adding:
to the server ovpn-file:
remote-cert-tls client

to the client ovpn-file:
remote-cert-tls server

Thanks again!

[TinCanTech]

I think you should check very carefully again.

This is what the manual says:

In a nutshell, --tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.

[Endstille]

OH, so basically it would just be a better idea to stay with port 1194, since tls-auth is only supported on OpenVPN's ports?

[TinCanTech]

Please don't jump to ridiculous conclusions ..

You can choose any port for openvpn.

[Endstille]

Hmm.. I think I've lost you then.

Does that mean I can just leave it be, monitor the activity with the added remote-cert-tls rules and if nothing significant happens in the first 3-ish days, leave it at that?

[TinCanTech]

If you configure TLS-auth correctly then you should never see those connection attempts because openvpn will simply drop the packet.

[Endstille]

Ah, i see. So something must be up with the ta.key (or with the spaces in the filepath). I'll relocate the key to a path that contains no spaces and respecify the location in the server-ovpn file. Quick question, did i need to sign the ta.key file with the ca-key?

[Endstille]

Ok, it has nothing to do with the spaces (removed the spaces between "Program Files" and restarted and the server refused to connect).

I could make a new ta.key-file but I think that's a subject for tomorrow (I still have some Cisco to study today!).

Thank you for your input though, i really appreciate it! I'll let you know more between now and 24-ish hours (depending on my mood to study and when i can fall asleep )

[Endstille]

Quick note while I have some time; remote-cert-tls server was already in the client configs but so I just missed it yesterday.
Adding that line (a second time) seem to have resulted in an "unused option: remote-cert-tls server" in the client logs; deleting that second mention of "remote-cert-tls server" seems to have fixed that.

This means the only only change I've made is adding "remote-cert-tls client" to the server config file and in the last 12 hours, nothing special showed up in the server logs.

I'll keep an eye on it and let you know in a few days.

In any case, i'd like to thank you again for your input!

[Endstille]

I've had it again today - seems to be an IP from around the globe. I tracerouted the IP partially and it gave at least 9 hops with a general direction going through america. At that point I interrupted it since that's definetely not an IP from this area.

I'll have to look into it later though since I don't have much time on my hands today.

2021-02-24 16:17:58 us=49492 ((me))/((ip me)) Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 3072 bit RSA
2021-02-24 16:30:22 us=180720 MULTI: multi_create_instance called
2021-02-24 16:30:22 us=180720 Re-using SSL/TLS context
2021-02-24 16:30:22 us=180720 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2021-02-24 16:30:22 us=180720 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2021-02-24 16:30:22 us=180720 Control Channel MTU parms [ dunno what this is but i'll leave it out ]
2021-02-24 16:30:22 us=180720 Data Channel MTU parms [ dunno what this is but i'll leave it out ]
2021-02-24 16:30:22 us=180720 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-server'
2021-02-24 16:30:22 us=180720 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-client'
2021-02-24 16:30:22 us=180720 TCP connection established with [AF_INET]185.156.72.6:64418
2021-02-24 16:30:22 us=180720 Socket flags: TCP_NODELAY=1 succeeded
2021-02-24 16:30:22 us=180720 TCPv4_SERVER link local: (not bound)
2021-02-24 16:30:22 us=180720 TCPv4_SERVER link remote: [AF_INET]185.156.72.6:64418
2021-02-24 16:31:22 us=373563 185.156.72.6:64418 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-02-24 16:31:22 us=373563 185.156.72.6:64418 TLS Error: TLS handshake failed
2021-02-24 16:31:22 us=373563 185.156.72.6:64418 Fatal TLS error (check_tls_errors_co), restarting
2021-02-24 16:31:22 us=373563 185.156.72.6:64418 SIGUSR1[soft,tls-error] received, client-instance restarting
2021-02-24 16:31:22 us=373563 TCP/UDP: Closing socket
2021-02-24 16:58:55 us=841593 MULTI: multi_create_instance called

[TinCanTech]

After testing this myself, it appears that openvpn on TCP does respond to the initial Syn packet, even with TLS protection in place.

[Pippin]

TCP, i don't think that's a surprise, handled by IP stack...

https://community.openvpn.net/openvpn/w ... acketsFlow

[Endstille]

You did more than i could ever ask! I really appreciate the fact that you simulated/confirmed this!

I'm primarily using TCP since I don't know/didn't find wether OpenVPN does any error detection/correction in software and I usually don't have a good connection with mobile internet (i'm honestly just hosting a personal VPN since i find it really convenient, not because of necessity).

OpenVPN 2.5.1 was released today though, I think i'll revoke all my certs/files, update openvpn, reinit my PKI and dig into the options of the new version. I don't know when i'll do that though (somewhere in the coming 14 days probably).

Thank you for your input!

[TinCanTech]

but it was a surprise because of what the manual says.. which is obviously only true for UDP.

Unless I misunderstand your words, I would think no because it is also handled by IP stack.

In both cases the packet arrives at the OpenVPN process and is dropped (in this case).
The response comes from the IP stack which sits in front of OpenVPN.