Einbruchsversuch über einen Docker-Container - was kann ich prüfen? Brauche Hilfe!

adahmen

Benutzer
Mitglied seit
12. Okt 2009
Beiträge
561
Punkte für Reaktionen
11
Punkte
38
Hallo Zusammen,

kurz zu meinem Setup:
DS 415+ (mit 8 GB Speicher) / schon auf DSM 7
Über FritzBox sind 5 Ports offen: Web-Station (darüber läuft Webtrees), Bitwarden, Traccar (hier 3 Ports offen - Web-Interface sowie 2 Ports für verschiedene Tracker)

Da ich aktuell Probleme mit meinem Tracker habe (sendet nicht mehr), habe ich mir ein Logfile von Traccar angeschaut und gesehen, dass es diese Nacht Aktivitäten gab. Sehr ungewöhnlich, da wie gesagt der Tracker keine Daten mehr sendet.

Parallel habe ich bemerkt, dass die Synology sehr langsam war. Nach Anmeldung war die RAM-Auslastung konstant bei 93%. Zuerst dachte ich, dass es die Surveillance Station war - war es aber nicht. Im Ressourcen-Monitor war keine Anwendung zu sehen, die viel RAM gezogen hat. Auch die Docker-Container sahen normal aus.
Ich habe das System neu gestartet und jetzt ist die RAM-Auslastung auf wieder bei normalen 30%. Das System fühlt sich normal an.
Alle Daten sind im Zugriff und lesbar.

Die Daten im Log waren in einem Zeitraum von 4:43 und 4:46 Uhr diese Nacht.

Man kann die Kommandos, die gesendet werden über eine Webseite von Traccer dekodieren und siehe da, es kamen keine GPS-Daten an, sondern diverse "Befehle".
Folgendes war zum Beispiel dabei:

GET / HTTP/1.0

oder

@PJL INFO ID

oder

HELP

oder

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1
MAN: "ssdp:discover"
MX: 2

oder

OPTIONS / HTTP/1.0

und es geht munter weiter.

Nach 3 Minuten war und ist wieder Ruhe.

Wie geschrieben läuft Traccar in einem Docker-Container.
Hier habe ich nachgeschaut und sehe aktuell keine offenen kritischen Lücken: https://www.cvedetails.com/vulnerability-list/vendor_id-19554/Traccar.html

Keine Ahnung ob das Speicher-Problem überhaupt zeitlich oder inhaltlich im Zusammenhang mit diesem Angriff zusammen hängt - oder ob es doch an DSM7 liegt.

Und keine Ahnung ob es nicht schon häufiger in de Logs solche Einträge gab. Ich schaue nicht wirklich regelmäßig die Logs von Traccar an.


Nun meine Fragen:
- Wie kritisch in der Angriff auf einen Docker-Container? Kann man am Ende auf das ganze System kommen? Welche Einstellungen für den Container sind wichtig (Netzwerk steht zum Beispiel auf "Bridge".
- Was sollte ich bzw. kann ich prüfen um "sicher" zu sein, dass nichts angerichtet wurde?
- Kann mein Speicher-Problem (volllaufen) mit DSM7 zusammen hängen?


Freue mich über Rückmeldungen, da ich schon ein wenig beunruhigt bin.


Viele Grüße,
Albert
 

TheGardner

Benutzer
Mitglied seit
30. Nov 2012
Beiträge
1.845
Punkte für Reaktionen
56
Punkte
74
Also es gab in der letzten Zeit Verschlüsselungen von ganzen DiskStations, weil die Hacker über Docker an (in) das System gekommen sind, sich Admin Rechte verschafft hatten und dann eben die ganzen Daten verschlüsselt hatten um eine Lösegeldforderung zu platzieren.
So wie sich das bei Dir anhört, könnte hier eine Ausspähung stattgefunden haben, die erstmal herausfinden soll, ob hier die Brechstange angesetzt werden kann.
Wie das genau aufläuft oder angelaufen ist, kann ich nicht sagen, aber ich hatte durch einen Kollegen damit zu tun, dem die DS verschlüsselt wurde und bin dann über die Suche darauf gestoßen, dass alles über nen "nicht up-todate" gehaltendes Docker Paket gestartet wurde.
 

Synchrotron

Benutzer
Sehr erfahren
Mitglied seit
13. Jul 2019
Beiträge
5.097
Punkte für Reaktionen
2.065
Punkte
259
Als erstes würde ich mir die Frage stellen, warum der ganze Kram überhaupt von außen erreichbar sein muss.

Wenn es denn so sein muss, würde ich mir überlegen, ob ich nicht den kompletten externen Zugriff auf VPN umstellen kann. Dann müsste sich jemand durch einen (1) gehärteten Zugang durchfrickeln, statt sich an allem abarbeiten zu können, was hinter einem normalen offenen Port so anzutreffen ist.

Denn so sieht das aus: Port ist offen (kann man automatisch finden), dann läuft ein Explorationsskript drüber und klopft mal an die Wand, ob da etwas hohl klingt. Darüber verliert niemand Schlaf, wenn es nicht eh aus einer Weltgegend kam, in der Sonne schon wieder aufging.
 

tproko

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.117
Punkte für Reaktionen
256
Punkte
129
Das was @TheGardner beschrieb, war zumindest in einem anderen Fall ioBroker und ein AdminTool für Syno dazu.

Auch hier gilt/galt, dass man so Zeug am Besten abschottet und nur im LAN hat. Ggf. VPN einrichten.
 

adahmen

Benutzer
Mitglied seit
12. Okt 2009
Beiträge
561
Punkte für Reaktionen
11
Punkte
38
Natürlich ist klar, dass am besten gar keine Ports offen sind.

Aber im Fall von traccar geht es nicht anders. traccar ist eine Lösung für GPS-Tracking - devices melden zyklisch ihren Standort sowie zusätzliche Informationen (z.B. Bewegung ohne Zündung an). Diese Devices (zumindest die, die ich kenne) können das nicht über VPN.
Wir nutzen das für unser Wohnmobil (werden gerne mal geklaut).

Bei Bitwarden ist es sicherlich anders - aber wir nutzen Bitwarden in der Familie (nicht im gleichen Haus wohnend) und auf diversen Devices.
Aus Sicht UX ist die Nutzung durch VPN deutlich komplexer - jedes Device und jeder Nutzer muss quasi permanent per VPN verbunden sein.

Mir ist vollkommen klar, dass offenen Ports ein Risiko darstellen. Es ist jedoch etwas anderes, wenn man diese Angriffe "sieht".

Habe im traccar Forum nachgefragt und der Entwickler der Software war wenig aufgeregt, da diese Angriffe normal sind. Sofern ich die aktuelle Version installiert habe (was ich habe), gibt es keine bekannten Schwachstellen.

Bei meinem Post ging es eher um die Frage, wir ich erkennen kann, ob jemand erfolgreich war.

Und nein, meine Daten sind nicht verschlüsselt und auch sonst ist nichts auffällig.
 

McFlyHH

Benutzer
Mitglied seit
02. Jan 2014
Beiträge
427
Punkte für Reaktionen
82
Punkte
28
...
Bei meinem Post ging es eher um die Frage, wir ich erkennen kann, ob jemand erfolgreich war.

Und nein, meine Daten sind nicht verschlüsselt und auch sonst ist nichts auffällig.

Z.B, wenn deine Daten gelöscht oder doch verschlüsselt sind (und du den Schlüssel nicht kennst) ;)
 

Ramihyn

Benutzer
Mitglied seit
14. Mai 2017
Beiträge
332
Punkte für Reaktionen
60
Punkte
34
Man könnte ja auch einfach mal auf die Idee kommen, dass man solche Anwendungen und die wichtigen Daten physisch voneinander trennen sollte.
Gewisse Dinge gehören nun einmal nicht auf ein NAS, auch wenn es die Resourcen hergeben, der Hersteller das irgendwie durch die Hintertür mit irgendeiner Krücke (Docker) unterstützt und es technisch möglich ist.
Manche Leute fordern den Genickschuss durch eine Ransomware ja förmlich heraus.

Wenn ich an die neuen Einschränkungen durch DSM 7 denke, steigt direkt wieder die Galle hoch - nativen Betrieb von JAVA-Applikationen unterbindet Synology auf einmal, aber Docker und allzu oft damit echte Einfallstore wird selbstredend weiterhin zugelassen. Das ist fast schon so kopflos wie die deutsche Coronapolitik.
 
  • Like
Reaktionen: the other

tproko

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.117
Punkte für Reaktionen
256
Punkte
129
nativen Betrieb von JAVA-Applikationen unterbindet Synology auf einmal

Ja, das ist spannend, wobei es zu erwarten war, dass was passieren muss, dachte eher es kommt noch ein Update aber gut, besser weg, als die uralten Versionen.
Was gab es bei DSM6? Java 8 und Java 7? Das eine EOL 2019, das andere EOL 2015.
Jetzt haben sie dann Java und auch darauf aufbauendes wie Tomcat halt nicht mehr im Store.

Alternativ kann Docker verwendet werden. Aber es bleibt sowieso dabei, egal ob nativ oder docker, ein bisschen Hausverstand schadet nicht, man kann auch mit nur einem Port alles kaputt machen - docker/java oder sonst was hin oder her.

Wie du sagst, evt. 2 Server hinstellen, Dinge trennen etc. damit selbst erfolgreiche Angriffe einfach egal sind.
 
  • Like
Reaktionen: the other

Ramihyn

Benutzer
Mitglied seit
14. Mai 2017
Beiträge
332
Punkte für Reaktionen
60
Punkte
34
Was gab es bei DSM6? Java 8 und Java 7? Das eine EOL 2019, das andere EOL 2015.
Schon recht, jedoch gibt es für nahezu jede Linuxvariante längst auch aktuelle OpenJDKs. Es wäre ziemlich einfach gewesen, das zu unterstützen. Auch unter DSM6 hat man nur einmal das veraltete Originalpaket installiert und anschliessend dann selbst direkt von Oracle die Updates gezogen und über den Updater eingespielt.
Mehr als einen Wrapper für diesen Updatemechanismus zum Einspielen eines OpenJDK bräuchte es ja gar nicht.
 

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.093
Punkte für Reaktionen
570
Punkte
194
Nutze mapmypos.com und schalte Traccar ab.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat