Ungewöhnlich viele (fremde) Verbindungen auf OpenVPN Server

Denik · Sep 23rd 2018

Hallo zusammen,

nachdem ich schon viele Beiträge in diesem Forum gelesen und verfolgt habe, habe auch ich jetzt mal ein Anliegen, bei dem ich nicht weiter komme.

Ich habe bei Netcup einen gemieteten VPS-Server mit CentOS 7, auf welchem unter anderem ein OpenVPN 2.4.6 Server läuft. Seit mehreren Tagen beobachte ich in der Log-Datei folgendes:

Code

Sun Sep 23 04:53:29 2018 us=828279 74.91.119.108:6336 TLS: Initial packet from [AF_INET]74.91.119.108:6336, sid=6a22eb44 5adb63fe
Sun Sep 23 04:53:30 2018 us=17301 74.91.119.108:2726 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep 23 04:53:30 2018 us=17456 74.91.119.108:2726 TLS Error: TLS handshake failed
Sun Sep 23 04:53:30 2018 us=17601 74.91.119.108:2726 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Sep 23 04:53:30 2018 us=17830 74.91.119.108:39595 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep 23 04:53:30 2018 us=17869 74.91.119.108:39595 TLS Error: TLS handshake failed
Sun Sep 23 04:53:30 2018 us=17950 74.91.119.108:39595 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Sep 23 04:53:30 2018 us=18031 74.91.119.108:55599 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep 23 04:53:30 2018 us=18054 74.91.119.108:55599 TLS Error: TLS handshake failed
Sun Sep 23 04:53:30 2018 us=18111 74.91.119.108:55599 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Sep 23 04:53:30 2018 us=365242 74.91.119.108:39851 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep 23 04:53:30 2018 us=365345 74.91.119.108:39851 TLS Error: TLS handshake failed
Sun Sep 23 04:53:30 2018 us=365495 74.91.119.108:39851 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Sep 23 04:53:30 2018 us=498140 MULTI: multi_create_instance called
Sun Sep 23 04:53:30 2018 us=498311 74.91.119.108:17454 Re-using SSL/TLS context
Sun Sep 23 04:53:30 2018 us=498355 74.91.119.108:17454 LZO compression initializing
Sun Sep 23 04:53:30 2018 us=498538 74.91.119.108:17454 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sun Sep 23 04:53:30 2018 us=498585 74.91.119.108:17454 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Sun Sep 23 04:53:30 2018 us=498649 74.91.119.108:17454 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Sun Sep 23 04:53:30 2018 us=498674 74.91.119.108:17454 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'

Display More

Diese Zugriffe gibt es von den verschiedensten IP Adressen und die Dauer ist auch immer unterschiedlich. Teilweise ist es nur ein Verbindungsversuch, teilweise dauern die Versuche auch eine halbe Stunde. Ebenfalls ist dies rund um die Uhr zu beobachten.

Am Freitag habe ich mir daher mit Fail2Ban einen Filter gebaut, welcher die IP Adressen nach drei Versuchen blockiert. Bis jetzt sind 88 unterschiedliche IP Adressen gesperrt, aber es kommen immer weiter neue dazu. Ich bin mir daher nicht mehr ganz sicher, ob dies der richtige Weg ist.

Eine konkrete Fragen von mir wäre: Handelt es sich hierbei wirklich um einen Versuch eine Verbindung mit meinem OpenVPN Server herzustellen (also den Tunnel zu knacken) oder habe ich die Logs vielleicht falsch interpretiert und es sind nur harmlose Bots, die verschiedene Server nach offenen Ports abfragen?

Vielleicht hat hier ja jemand eine Idee.

Viele Grüße

Denik

mainziman · Sep 23rd 2018

da die IPs nicht von Dir stammen, sind hier tatsächlich 'böse jungs' unterwegs;

um herauszufinden, ob diese tatsächlich eine Verbindung zu stande gebracht haben

oder es nur erfolglose Versuche waren, müsstest in diversen anderen Logs nachsehen;

die Frage ist, wie hast Du das ganze abgesichert?

Du brauchst ja f. die Verbindung ein Zertifikat, und dieses wurde von einem CA-Zert. abgeleitet;

ist dies auch so eingestellt, daß nur Client-Zert. welche von diesem einem CA-Zer. abgeleitet wurden,

erlaubt sind z.B.?

perryflynn · Sep 23rd 2018

Auf welchem Port hast Du den OpenVPN denn laufen?

Denik · Sep 23rd 2018

Vielen Dank für die schnelle Antwort.

Also der Port ist Standard 1194.

Abgesichert ist das Ganze wie in jeder Standard Anleitung. Also Client Zertifikate von einer CA erstellt. Jeder Client hat seine eigene .key-Datei und .cert. Es ist nur eine Verbindung pro Client Zertifikat erlaubt.

Wenn ich später wieder zu Hause bin kann ich auch die Server.conf und eine client.ovpn zeigen, sofern erforderlich.

Andreas B · Sep 23rd 2018

Was ich empfehlen kann: Wenn alle Verwender des VPNs Versiert genug sind würde ich den Port-Zugriff schützen. Mit iptables-recent kann man z.B. ganz simpel ein Port-Knocking implementieren. Das ist effektiver als das simple Ändern des Ports.

Bei Bedarf kann ich auch eine Bespiel-Konfig zur Verfügung stellen.

mainziman · Sep 23rd 2018

hier mal meine /etc/openvpn/server.conf

(ebenfalls openvpn 2.4.6 aber unter CentOS 6)

Code

# OpenVPN server ip address
local xxx.xxx.xxx.xxx

# OpenVPN server port
port 1194

# OpenVPN server protocol: udp or tcp
proto udp

# "dev tun" will create a routed IP tunnel.
dev tun

# "topology net30" with create /30 p2p subnets
topology net30

# Validate correct x509
# Client certificate attributes
remote-cert-tls client

# Certificate Configuration

# CA certificate(s) (Root CA+OpenVPN CA)
ca /etc/openvpn/keys/cachain-sslca.crt

# Server Certificate
cert /etc/openvpn/keys/vpnsrvr.crt

# Server Key: keep this secret
key /etc/openvpn/keys/vpnsrvr.key

# DH key
dh /etc/openvpn/keys/dh2048.pem

# Internal IP/Mask
server 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/ccd
ccd-exclusive

verify-client-cert require

verify-hash xx:xx:xx:xx:xx:xx:...:xx:xx:xx SHA1

# Secure VPN server:
# - 0 on server side
# - 1 on client side
tls-auth ta.key 0

tls-verify /etc/openvpn/verify.pl

# Define cipher
#cipher DES-EDE3-CBC
cipher AES-128-CBC

keepalive 10 120
comp-lzo
persist-key
persist-tun
daemon

max-clients 22

user nobody
group nobody

log-append /var/log/openvpn.log

# Log Level
verb 3

# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1

Display More

hier das verify.pl script

Perl

#!/usr/bin/perl

die "usage: verify.pl x509-depth x509-subject" if (@ARGV != 2);

( $depth, $subject ) = @ARGV;

if ( $depth == 0 ) {
        if ( $subject =~ /CN=([^,]+)/ ) {
                $cn = $1;

                open(my $X509CN, "/etc/openvpn/x509-cn.text") or exit 1;

                while( my $line  = <$X509CN> ) {
                        if ( $line !~ /^[[:space:]]*(#|$)/o ) {
                                chop( $line );
                                if ( $line eq $cn ) {
                                        exit 0;
                                }
                        }
                }

                close( $X509CN );
        }

        exit 1;
}

exit 0;

Display More

und der im skript referenzierte text file: /etc/openvpn/x509-cn.text

enthälft eine Auflistung der möglichen CNs der Client-Certificates Subjects

Anmerkung: ich bin meine eigene CA und hab daher das OpenVPN CA als Intermediate vom Root CA abgeleitet

macht den Einbruch etwas schwieriger, weil um da was veranstalten zu können braucht er schon a bssi viel

(die private Keys der CA Certificates sind natürlich zu Hause sicher verwahrt)

angenommen ein Client hat im Zert. als CN vpnclnt.guest

dann befindet sich im Verz. /etc/openvpn/ccd dann der File vpnclnt.guest mit z.B. folgendem Inhalt

Code

# This line will redirect all traffic through our OpenVPN
push "redirect-gateway def1 bypass-dhcp bypass-dns"

# Provide DNS servers to the client
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Provide DNS name to the client
push "dhcp-option DOMAIN domain"

# Provide fixed IP
ifconfig-push 192.168.1.62 192.168.1.63

Display More

welche DNS-Server ihr verwendet sei euch überlassen;

bei domain empfehle ich xxxx.arpa.home

Denik · Sep 23rd 2018

Hallo zusammen,

erneut vielen Dank für für Antworten.

Bezüglich iptables-recent müsste ich mich erst einmal ein bisschen einlesen. Da kann ich so spontan noch nicht sagen, ob dies eine Alternative wäre.

Das verify.pl Script verwende ich sogar schon

Hier kommt mal die aktuelle Konfiguration von mir:

Server:

Code

local x.x.x.x
port 1194
proto udp
dev tun
management 127.0.0.1 5555
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.0.0 255.255.255.0 10.8.0.2
route 192.168.178.0 255.255.255.0 10.8.0.3
route 192.168.1.0 255.255.255.0 10.8.0.4
push "dhcp-option DNS 10.8.0.1"
client-to-client
keepalive 10 120
cipher AES-256-CBC
compress
comp-lzo yes
push "comp-lzo yes"
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn.log
verb 4
tls-verify "./verify-cn userlist.txt"
script-security 2

Display More

Client:

Code

client
dev tun
proto udp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
comp-lzo yes
verb 3

Display More

Was ich aktuell nicht verwende ist folgendes:

Code

#For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
#   openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret

Display More

Wäre dies vielleicht sinnvoll?

Grüße

Denik

mainziman · Sep 23rd 2018

Ja und zusätzlich noch

verify-client-cert require

verify-hash xx:xx:xx:xx:xx:xx:...:xx:xx:xx SHA1

den hash bekommst mit

openssl x509 -fingerprint -in ca.crt

Denik · Sep 23rd 2018

Hallo zusammen,

ich habe jetzt ein paar Dinge umgesetzt:

tls-auth ta.key
verify-client-cert require
verify-hash xx:xx:xx:xx:xx:xx:...:xx:xx:xx SHA

Im Log sieht es jetzt wie folgt aus:

Code

Sun Sep 23 18:31:31 2018 us=961663 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:31 2018 us=961788 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:36 2018 us=859728 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:36 2018 us=859851 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:40 2018 us=545131 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:40 2018 us=548046 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:41 2018 us=813450 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:41 2018 us=813687 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987
Sun Sep 23 18:31:46 2018 us=740685 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]79.133.54.200:9987

Die Tatsache dass Verbindungsversuche stattfinden kann keiner von uns ändern. Aber ich fühle mich mit den oben genannten Punkten doch schon etwas sicherer als vorher.

Vielen Dank für die Hilfe

Viele Grüße

Denik

mainziman · Sep 23rd 2018

Gut,

wenn Dir danach ist, kannst ja selektiv IPs mit IPtables sperren

iptables -I INPUT -i eth0 -s 79.133.54.200 -j DROP

douzer · Sep 23rd 2018

Quote from mainziman

wenn Dir danach ist, kannst ja selektiv IPs mit IPtables sperren

Na da bist mit fail2ban wohl erfolgreicher. Die Verbindungen werden sehr wahrscheinlich aus allen Regionen der Welt sein

KB19 · Sep 24th 2018

mainziman Warum nutzt Du zur Validierung des CN eigentlich zusätzlich ein Perlscript? Wäre das mit --ccd-exclusive und leeren Dateien im CCD für erlaubte CNs nicht schon ausreichend? Oder übersehe ich hier etwas?

mainziman · Sep 24th 2018

KB19 das ist die Frage zu welchem Zeitpunkt diese Validierung stattfindet;

das Perscript das die CNs validiert ermöglicht Dir den Aufbau der SSL-Verbindung; sprich kommt hier ein Client mit einem CN der nicht in der Liste vorkommt, nützt der File im CCD auch nichts, der SSL-Verbindungsaufbau wird abgebrochen;

im anderen Fall, wenn dieses Perlscript weggelassen wird, erfolgt erst der vollstándige Aufbau der SSL-Verbindung bis die Erkenntnis kommt, daß mangels CCD-File keine VPN-Verbindung möglich ist;

so zumindest habe ich das verstanden;

bei mir sind die CCD-Files nicht leer, weil jeder hier seine eigene fixe IP bekommt;

Denik · Sep 24th 2018

Quote from douzer

Na da bist mit fail2ban wohl erfolgreicher. Die Verbindungen werden sehr wahrscheinlich aus allen Regionen der Welt sein

Ja, das denke ich auch. Die IP Adressen kommen wirklich von überall. Hatte am Wochende mal ausrechnen lassen, wie viele verschiedene IP Adressen es waren. Es waren so um die 100 Adressen.

Habe jetzt Fail2Ban so eingestellt, dass bei 3 Fehlversuchen die IP für eine Stunde gesperrt wird.

mainziman · Sep 25th 2018

ich hab quasi Fail2Ban neu erfunden; per Cronjob einfach Sperre mit IPtables auf ewig;

Tags