EreignisID 56 TermDD an W7-PC
Hi@all,
Ich war gestern per Teamviewer auf einem entfernten PC (Arztpraxis), um ein paar Einstellungen zu kontrollieren.
Die Mitarbeiterin beschwert sich, dass deren Programm "abstürzt".
Während sie mir das versucht zu erklären passiert folgendes:
Mitarbeitern "schreit":
"Da passiert es schon wieder!", es scheint sich auf deren PC eine RDP Sitzung zu öffnen (w7pro), ich sehe noch einen vermeintlichen Hostnamen/usernamen "PC-PC", den es nicht in der Domäne (w2k8) gibt, mehr nicht.
Geistesgegenwärtig rufe ich "Drück alt-STRG-Entf", Anmeldung abgewendet.
In den Ereignislogs.
- Quelle : termDD, ID 56 Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP (BSP)
Ich bin total perplex, das ganze geht seit gut zwei Monaten, zumindest diese IDs
Remoteunterstützung habe ich abgeschaltet, RDP ist nur für den lokalen Admin zugelassen (mit dem die leider laut Softwarehersteller arbeiten "müssen").
Leider finde ich hauptsächlich Treiberprobleme zu diesem Fehler, die scheinen hier ja eher nicht der Fall zu sein.
Im DHCP/DNS des Servers finde ich natürlich keinen passenden PC, arp und nslookup lösen mir auch nichts passendes auf.
Zum Client:
Standart-HP PC, Win7 pro, erweitert um div Arztsoftware+Vsphere Client und VMWare Workstation 12 pro, dazu GDATA IS, das Netzwerk ist mittels Routerkaskade getrennt.
Übertreibe ich, wenn ich von einem gezielten Angriff ausgehe ?!
Oder hat jemand eine rationalere Erklärung/Tipp für mich ?!
Danke und Gruß
Carsten
Ich war gestern per Teamviewer auf einem entfernten PC (Arztpraxis), um ein paar Einstellungen zu kontrollieren.
Die Mitarbeiterin beschwert sich, dass deren Programm "abstürzt".
Während sie mir das versucht zu erklären passiert folgendes:
Mitarbeitern "schreit":
"Da passiert es schon wieder!", es scheint sich auf deren PC eine RDP Sitzung zu öffnen (w7pro), ich sehe noch einen vermeintlichen Hostnamen/usernamen "PC-PC", den es nicht in der Domäne (w2k8) gibt, mehr nicht.
Geistesgegenwärtig rufe ich "Drück alt-STRG-Entf", Anmeldung abgewendet.
In den Ereignislogs.
- Quelle : termDD, ID 56 Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP (BSP)
- 185.93.185.244; 118.193.22.250;
- 185.93.185.237...
Ich bin total perplex, das ganze geht seit gut zwei Monaten, zumindest diese IDs
Remoteunterstützung habe ich abgeschaltet, RDP ist nur für den lokalen Admin zugelassen (mit dem die leider laut Softwarehersteller arbeiten "müssen").
Leider finde ich hauptsächlich Treiberprobleme zu diesem Fehler, die scheinen hier ja eher nicht der Fall zu sein.
Im DHCP/DNS des Servers finde ich natürlich keinen passenden PC, arp und nslookup lösen mir auch nichts passendes auf.
Zum Client:
Standart-HP PC, Win7 pro, erweitert um div Arztsoftware+Vsphere Client und VMWare Workstation 12 pro, dazu GDATA IS, das Netzwerk ist mittels Routerkaskade getrennt.
Übertreibe ich, wenn ich von einem gezielten Angriff ausgehe ?!
Oder hat jemand eine rationalere Erklärung/Tipp für mich ?!
Danke und Gruß
Carsten
Please also mark the comments that contributed to the solution of the article
Content-ID: 311502
Url: https://administrator.de/contentid/311502
Printed on: October 7, 2024 at 23:10 o'clock
5 Comments
Latest comment
nabend..
Ich war gestern per Teamviewer auf einem entfernten PC (Arztpraxis), um ein paar Einstellungen zu kontrollieren.
Die Mitarbeiterin beschwert sich, dass deren Programm "abstürzt".
Während sie mir das versucht zu erklären passiert folgendes:
Mitarbeitern "schreit":
"Da passiert es schon wieder!", es scheint sich auf deren PC eine RDP Sitzung zu öffnen (w7pro), ich sehe noch einen vermeintlichen Hostnamen/usernamen "PC-PC", den es nicht in der Domäne (w2k8) gibt, mehr nicht.
Geistesgegenwärtig rufe ich "Drück alt-STRG-Entf", Anmeldung abgewendet.
In den Ereignislogs.
- Quelle : termDD, ID 56 Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP (BSP)
die erste ip kommt mit bekannt vor... ist was aus der ukraine...
ist wohl ein botnet etc...
Remoteunterstützung habe ich abgeschaltet, RDP ist nur für den lokalen Admin zugelassen (mit dem die leider laut Softwarehersteller arbeiten "müssen").
Leider finde ich hauptsächlich Treiberprobleme zu diesem Fehler, die scheinen hier ja eher nicht der Fall zu sein.
Im DHCP/DNS des Servers finde ich natürlich keinen passenden PC, arp und nslookup lösen mir auch nichts passendes auf.
Zum Client:
Standart-HP PC, Win7 pro, erweitert um div Arztsoftware+Vsphere Client und VMWare Workstation 12 pro, dazu GDATA IS, das Netzwerk ist mittels Routerkaskade getrennt.
mach mal ein ordentlich AV drauf- und was versprechen sich die leute immer mit einer router kaskade- wenn ein und ausgehende ports brav weitergeleitet werden...
ich würde die kiste mal offline scannen... und die vm´s oder was da auch immer laufen mag.
Übertreibe ich, wenn ich von einem gezielten Angriff ausgehe ?!
na ja- gezielt wohl nicht- eher zufall über webseite mit wimmelbildern etc.. auf was helferinen so eben stehen... oder über mail...
Danke und Gruß
Carsten
Frank
Ich war gestern per Teamviewer auf einem entfernten PC (Arztpraxis), um ein paar Einstellungen zu kontrollieren.
Die Mitarbeiterin beschwert sich, dass deren Programm "abstürzt".
Während sie mir das versucht zu erklären passiert folgendes:
Mitarbeitern "schreit":
"Da passiert es schon wieder!", es scheint sich auf deren PC eine RDP Sitzung zu öffnen (w7pro), ich sehe noch einen vermeintlichen Hostnamen/usernamen "PC-PC", den es nicht in der Domäne (w2k8) gibt, mehr nicht.
Geistesgegenwärtig rufe ich "Drück alt-STRG-Entf", Anmeldung abgewendet.
In den Ereignislogs.
- Quelle : termDD, ID 56 Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP (BSP)
- 185.93.185.244; 118.193.22.250;
- 185.93.185.237...
ist wohl ein botnet etc...
Ich bin total perplex, das ganze geht seit gut zwei Monaten, zumindest diese IDs
kann gut seinRemoteunterstützung habe ich abgeschaltet, RDP ist nur für den lokalen Admin zugelassen (mit dem die leider laut Softwarehersteller arbeiten "müssen").
Leider finde ich hauptsächlich Treiberprobleme zu diesem Fehler, die scheinen hier ja eher nicht der Fall zu sein.
Im DHCP/DNS des Servers finde ich natürlich keinen passenden PC, arp und nslookup lösen mir auch nichts passendes auf.
Zum Client:
Standart-HP PC, Win7 pro, erweitert um div Arztsoftware+Vsphere Client und VMWare Workstation 12 pro, dazu GDATA IS, das Netzwerk ist mittels Routerkaskade getrennt.
ich würde die kiste mal offline scannen... und die vm´s oder was da auch immer laufen mag.
Übertreibe ich, wenn ich von einem gezielten Angriff ausgehe ?!
Oder hat jemand eine rationalere Erklärung/Tipp für mich ?!
alles offline prüfen..Danke und Gruß
Carsten
Hallo,
klingt nicht prickelnd.
Leider ist deine Fehlerbeschreibung auch nicht einfach nachvollziehbar und mir ist einiges unklar.
Der PC bzw. das Netzwerk hat ein noch unbekanntes Einfallstor welches erst einmal zu finden (und zu schließen) ist.
Bis dahin: Router aus, keine Verbindung ins Internet, schriftliche Meldung an Vorgesetzten, Auftraggeber und ggf. übergeordnete Instanz.
-
Verwunderlich ist die Tatsache, daß von außerhalb per RDP auf diesen PC zugegriffen werden kann.
Während ich dies schreibe fällt mir was auf bzw. ein:
Ist auf den Routern auf irgendeine Art und Weise Port 3389 von außerhalb erreichbar gemacht worden, damit sich der Hersteller (oder sonst irgendwer) sich per RDP mit diesen Client verbinden kann ?
Wenn ja, sollte das Konstrukt nochmal überdacht werden. Hart ausgedrückt: wer sich so was einfallen lässt bzw. einrichtet handelt imho grob fahrlässig und ist ungeeignet.
Wenn von außerhalb keinerlei "Zugang" eingerichtet ist: siehe oben: abschalten und Fehlersuche.
Gruß
CH
klingt nicht prickelnd.
Leider ist deine Fehlerbeschreibung auch nicht einfach nachvollziehbar und mir ist einiges unklar.
Übertreibe ich, wenn ich von einem gezielten Angriff ausgehe ?!
Es muß kein gezielter Angriff sein, es kann (!) sogar noch schlimmer sein:Der PC bzw. das Netzwerk hat ein noch unbekanntes Einfallstor welches erst einmal zu finden (und zu schließen) ist.
Bis dahin: Router aus, keine Verbindung ins Internet, schriftliche Meldung an Vorgesetzten, Auftraggeber und ggf. übergeordnete Instanz.
-
Verwunderlich ist die Tatsache, daß von außerhalb per RDP auf diesen PC zugegriffen werden kann.
Während ich dies schreibe fällt mir was auf bzw. ein:
RDP ist nur für den lokalen Admin zugelassen (mit dem die leider laut Softwarehersteller arbeiten "müssen")
OK, RDP Server läuft auf dem Client aber:Ist auf den Routern auf irgendeine Art und Weise Port 3389 von außerhalb erreichbar gemacht worden, damit sich der Hersteller (oder sonst irgendwer) sich per RDP mit diesen Client verbinden kann ?
Wenn ja, sollte das Konstrukt nochmal überdacht werden. Hart ausgedrückt: wer sich so was einfallen lässt bzw. einrichtet handelt imho grob fahrlässig und ist ungeeignet.
Wenn von außerhalb keinerlei "Zugang" eingerichtet ist: siehe oben: abschalten und Fehlersuche.
Gruß
CH
OK, RDP Server läuft auf dem Client aber:
Ist auf den Routern auf irgendeine Art und Weise Port 3389 von außerhalb erreichbar gemacht worden, damit sich der Hersteller (oder sonst irgendwer) sich per RDP mit diesen Client verbinden kann ?
muss nicht sein...Ist auf den Routern auf irgendeine Art und Weise Port 3389 von außerhalb erreichbar gemacht worden, damit sich der Hersteller (oder sonst irgendwer) sich per RDP mit diesen Client verbinden kann ?
Wenn ja, sollte das Konstrukt nochmal überdacht werden. Hart ausgedrückt: wer sich so was einfallen lässt bzw. einrichtet handelt imho grob fahrlässig und ist ungeeignet.
da ist was wahres dran... sowas macht man nur über ein vpn!Wenn von außerhalb keinerlei "Zugang" eingerichtet ist: siehe oben: abschalten und Fehlersuche.
ich kenne das eine oder andere botnet was rdp nutzt... es werden von innen rdp verbindungen aufgebaut!!!Gruß
CH
Guten Morgen
@9045:
Gute Idee mit dem RDP Port, den hatte ich tatsächlich mal öffnen lassen, konnte den nie gebrauchen, den lasse ich jetzt schließen.
ihr seit ja wahnsinnig- sowas macht man nicht.
Allerdings sollen diese "Angriffe" wohl schon anderweitig gesichtet worden sein (laut genau jener Mitarbeiterin)
warum ist da noch nix früher unternommen worden ?
...und ich hoffe du hast das Praxis EDV System stillgelegt- bis alles dicht ist- und geprüft ist!
so darf auf keinen fall weitergearbeitet werden.
Carsten
Frank
@9045:
Gute Idee mit dem RDP Port, den hatte ich tatsächlich mal öffnen lassen, konnte den nie gebrauchen, den lasse ich jetzt schließen.
Der ist sogar für diesen Client geöffnet worden, in die Praxis wollte ich eh per VPN rein.
und nur per vpn...Allerdings sollen diese "Angriffe" wohl schon anderweitig gesichtet worden sein (laut genau jener Mitarbeiterin)
Die Kaskade ist eine Vorschrift, darüber werden Abrechnungen und Patientendaten geholt.
@Frank:
AV ist halt "nur" der GDATA IS, ich werde wohl mal mit ner Desinfec´t dorthin watscheln.
Die VM kommt nur zum Einsatz, wenn der Server die Grätsche macht, dann wird bis zur Reparatur besagter/betroffener einspringen müssen.
Solange ist die VHD angelegt und "bestückt", aber offline.
Schon einmal danke und jetzt gute Nacht
ich hoffe du hast von Patientendaten geträumt, die per rdp die praxis verlassen haben!?!@Frank:
AV ist halt "nur" der GDATA IS, ich werde wohl mal mit ner Desinfec´t dorthin watscheln.
Die VM kommt nur zum Einsatz, wenn der Server die Grätsche macht, dann wird bis zur Reparatur besagter/betroffener einspringen müssen.
Solange ist die VHD angelegt und "bestückt", aber offline.
Schon einmal danke und jetzt gute Nacht
...und ich hoffe du hast das Praxis EDV System stillgelegt- bis alles dicht ist- und geprüft ist!
so darf auf keinen fall weitergearbeitet werden.
Carsten