Über Nacht meldete die Securepoint UTM eines Kunden vier möglicherweise gefährliche Verbindungen und unterband diese. Wir gingen der Sache ein wenig nach.

Sozusagen der Kopf der Alert-Mail sieht so aus:

General
 
Firewall name: firewall.domain.local
Status: ALERT
Date: 15.07.2020 - 02:01:50
Source: spsysprocd
Message:
FORWARD - Potentially dangerous connection was blocked:
incoming interface eth1, outbound interface wan0,
source address 192.168.0.7, destination address 142.11.210.231,
protocol UDP, source port 58305, destination port 123

Kurzum: Ein Gerät aus dem LAN hat versucht eine unerwünschte Verbindung aufzubauen und wurde daran gehindert.

Hinter der IP-Adresse “192.168.0.7” steckt in diesem Fall ein Cisco SPA112 (Analog-VoIP-ATA). Das alleine erschien uns schon merkwürdig. Der Port 123/udp wiederum ist altbekannt, da es sich dabei um NTP, also den Zeitsynchronisation, handelt.

Verdächtig ist das Ganze dennoch, also wurde die Konfiguration des ATAs überprüft. Die Firmware ist aktuell und auch sonst viel nichts negatives auf.

Als NTP-Quelle ist “0.ciscosb.pool.ntp.org” im ATA hinterlegt, prüft man die Namensauflösung ergibt das folgendes:

C:\Users\administrator>nslookup 0.ciscosb.pool.ntp.org
Server: localhost
Address: 127.0.0.1

Nicht autorisierende Antwort:
Name: 0.ciscosb.pool.ntp.org
Addresses: 217.79.179.106
159.69.150.81
129.69.1.170
136.243.202.118

Die genannte externe IP ist also nicht (mehr) vorhanden. Die IP-Adresse “142.11.210.231” ist bereits 2019 als Malware-URL in Erscheinung getreten.

Was genau nun geschehen ist konnte so spontan nicht ermittelt werden. Vermutlich, das ist allerdings reine Spekulation, war die Namensauflösung oder schlimmstenfalls der NTP-Pool kompromittiert, es kann allerdings auch nur dieser eine Server gewesen sein.

Update 27.01.2023

Dieses Mal traf es uns, genau genommen meinen PC. Kurz nach dessen Einschalten bzw. Anmelden meldete die Securepoint UTM verdächtige ausgehende Verbindungen:

Allgemein 
Firewallname <Firewallname>
Status ALARM 
Datum 27.01.2023 - 08:37:14 
Quelle spsysprocd 
Nachricht FORWARD - Potenziell gefährliche Verbindung blockiert:
Eingehendes Interface A1, ausgehendes Interface wan0,
Quelladresse <Quell-IP>, Zieladresse 92.205.64.102,
Protokoll TCP, Quellport 49812, Zielport 443,

Löst man die IP-Adresse auf, erhält man folgendes:

C:\Windows\system32>nslookup 92.205.64.102
Name: sh11813.ispgateway.de
Address: 92.205.64.102

Kurzum ein Server bei Host Europe, noch dazu eine deutsche TLD und der Server steht möglicherweise in Frankreich, also eher untypisch für irgendetwas negatives. Nach der IP im Internet gesucht stellt sich raus, das diese zu KeePass gehört:

Sourceforge – KeePass – Communication denied by rule from ESET

Die Gegenprüfung bestätigt dies:

C:\Windows\system32>nslookup KeePass.info
Name: KeePass.info
Addresses: 2a00:1158:5:866::
92.205.64.102

Die Verbindungsversuche gehören zur automatischen Update-Prüfung. Weiteres Licht ins Dunkel bringt dieser Post:

Sourceforge – KeePass – IP address hosting keypass.info website on abuseipdb.com blacklist !?!?

Das Problem dürfte sein, das der Server von mehreren Kunden, nicht nur von KeePass, genutzt wird. Und da könnte mitunter ein faules Ei mit dabei sein.

Schaut man beispielsweise bei AbuseIPDB finden sich recht aktuelle Beiträge, das von dieser IP/diesem Server aus mutmaßlich Angriffe gefahren wurden und wohl auch werden:

https://www.abuseipdb.com/check/92.205.64.102

Das es nun auch KeePass.info trifft, kann als Kollateralschaden betrachtet werden.

Update 09.10.2023

Hier ein weiteres Beispiel: Diesmal geht es um eine FRITZ!Box 7490 mit aktueller Firmware (7.57) die als IP-Client läuft, also kein Router ist, sondern lediglich für DECT und SmartHome herhalten tut. Eine vorgeschaltete Securepoint UTM meldete über das vergangene Wochenende immer wieder verdächtige Verbindungen die unterbunden wurden. Erneut ging es um NTP, sprich: Die Fritte wollte die Uhrzeit synchronisieren.

FORWARD - Potenziell gefährliche Verbindung blockiert:
Eingehendes Interface LAN2, ausgehendes Interface A0,
Quelladresse 192.168.0.3, Zieladresse 51.38.113.118,
Protokoll UDP, Quellport 45698, Zielport 123

Die Ziel-IP gehört zum Hoster OVH und schaut man nach der Reputation dieser Adresse z.B. unter AbuseIPDB wird schnell klar, das da nicht nur gute Sachen drüber laufen. Per Voreinstellung versucht eine AVM FRITZ!Box die Zeit mit

2.europe.pool.ntp.org

zu synchronisieren.  Vermutlich war die genannte IP Teil dieses Pools und das Ganze ist mit hoher Wahrscheinlichkeit erneut ein Kollateralschaden, damit ist gemeint: Der eigentliche Zeitserver ist nicht bösartig, aber ein anderer Kunde “hinter” der gleichen IP allerdings schon, vorausgesetzt das System wurde nicht kompromittiert. Jetzt könnte man hergehen und der Fritte sagen, sie solle einen anderen Zeitserver verwenden, aber da gibt es ein kleines Problem.

Läuft eine FRITZ!Box als Router, kann unter

Heimnetz - Netzwerk - Netzwerkeinstellungen

ein Zeitserver angegeben werden, allerdings ist diese Option im IP-Client-Modus nicht vorhanden oder anders ausgedrückt: Man kann in diesem Modus keinen (anderen) Zeitserver konfigurieren. Das ist Schade und so ergeben sich daraus folgende Möglichkeiten:

  • Die FRITZ!Box neu starten  (damit der DNS-Cache geleert wird, womöglich erscheint die verdächtige IP  nicht mehr bei einer aktuellen Namensauflösung).
  • Die Kommunikation via Portfilter-Regel unterbinden.
  • Im DNS-Server einen eigenen Eintrag für “2.europe.pool.ntp.org” erstellen und bei Auflösung auf eine andere IP-Adresse (z.B. einen internen Zeitserver) zeigen. Am Beispiel der Securepoint UTM kann das quick & dirty so aussehen:

    Es handelt sich hierbei um eine Forward-Zone. Im Portfilter muss dann noch eine Regel erstellt werden, die “network-time” auf dem eingehenden Interface zulässt. Am Beispiel der FRITZ!Box sieht man dann unter “System – Ereignisse” irgendwann oder nach einem Neustart das es (wieder) läuft:

    09.10.23 11:28:53 Die Systemzeit wurde erfolgreich aktualisiert von Zeitserver 192.168.0.1.
  • Das Ganze aussitzen.

Quellen

AVM – Wissensdatenbank – Zeitsynchronisation (NTP) für FRITZ!Box und Netzwerkgeräte einrichten

KH EDV Systeme – Tipps – FritzBox 7490 / 7530 / 7590 – als Zeitserver einrichten (NTP)

Update 10.07.2024

Und mal wieder ein Treffer, bei dem es etwas zu klären galt:

Firewallname firewall.domain.tld
Status ALARM
Datum 09.07.2024 - 16:42:28
Quelle spsysprocd
Nachricht FORWARD - Potenziell gefährliche Verbindung blockiert:
Eingehendes Interface LAN3, ausgehendes Interface A0, Quelladresse 192.168.2.109,
Zieladresse 188.114.96.3, Protokoll TCP, Quellport 49772, Zielport 443

Schaut man nach der Ziel-IP beispielsweise hier

https://www.abuseipdb.com/check/188.114.96.3

stellt man zum einen fest das diese bereits negativ aufgefallen ist und das sie zu CloudFlare gehört. Letzteres macht es nicht einfacher herauszubekommen worum es eigentlich geht. Fairerweise muss dazu erwähnt werden, das es nicht unbedingt was schlimmes sein muss, schließlich wird eine IP eines CDN für eine Vielzahl an Diensten, im Guten wie im Schlechten, genutzt.

Aber welche Anwendung funkt denn da nun rum? Da die Alarme nur sporadisch kamen konnte man auf dem Quell-Computer mittels CurrPorts zunächst nichts feststellen. Die Lösung bestand darin mit dem Process Monitor bis zum nächsten Alarm alles was mit der Ziel-IP kommuniziert zu erfassen:

  • Den Process Monitor starten und die Erfassung (“Capture”) stoppen.
  • Einen neuen Filter mit “Path” –  “contains” – “188.114.96.3” setzen.
  • Die Erfassung wieder starten und abwarten.

“Path” irritiert als Bezeichnung an dieser Stelle etwas, in dieser Spalte stehen neben Dateisystemzugriffen unter anderem auch Netzwerkzugriffe drin.

So zeigte sich nach einer Weile eine *.exe-Datei, die zu einer Kunden-Anwendung gehört, die ab und an mit einem Management-Server kommuniziert. Offenbar hängt da CloudFlare dazwischen und so kommt es aufgrund der aktuell negativen Reputation der IP-Adresse zu den besagten Alarmen.