Jump to content

Kommunikation zwischen vm in Workgroup und vm in Domäne


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

ich habe eine WS 2019 VM, welche aus Sicherheitsgründen in der Arbeitsgruppe WORKGROUP ist und eine WS 2016 VM, welche in der Domäne ist. Netzwerktechnisch ist zwischen diesen beiden VM's alles erlaubt. ICMP funktioniert auch testweise zu beiden Seiten.

Der WS 2016 ist der Administrationsserver einer Antivirenlösung und soll nun den Antiviren Client auf die VM in der WORKGROUP ausrollen. Hierzu wäre es natürlich erstmal hilfreich, wenn der Administrationsserver den Client überhaupt findet.

 

Im Wireshark Trace des Administrationsservers sehe ich immer folgende Meldungen (der "User:", den ich unkenntlich gemacht habe, hat folgendes Namensschema: "DOMAIN\HOSTNAME$"), während ich die Gerätesuche anstoße

 

 

 

Im Wireshark Trace des Clients, der vom Administrationsserver gefunden werden soll sehe ich folgende Meldungen, wenn die Suche angestoßen wird (der User, den ich hier unkenntlich gemacht habe, ist der gleiche)

 

 

 

 

  

Zur Info, die Windows Firewalls aller Netzwerkprofile auf dem WS 2019 sind aus.

 

Weiß gar irgendwie nicht mehr weiter

 

bearbeitet von sd2019
Link zu diesem Kommentar

Hi,

vor 58 Minuten schrieb sd2019:

Hierzu wäre es natürlich erstmal hilfreich, wenn der Administrationsserver den Client überhaupt findet.

hierzu wäre es hilfreich, zu wissen, wie der Server den Client denn überhaupt sucht (und evtl. um welche AV Lösung es sich handelt).

 

Muss der Server den Client denn zwingend finden oder kann man dem Server auch einfach einen DNS Namen an die Hand geben und eine Installation starten? Oder ggfs. noch simpler: Ein Installationpaket am Server generieren und dieses von Hand auf dem Client installieren.

 

Gruß

Jan

Link zu diesem Kommentar

Hallo @sd2019,

 

mit dem Netzwerktrace kann ohne Anwendungsbezug nichts gefangen werden. Wir alle haben ja nicht die Traces aller Anwendungen auswendig im Kopf. Hier brauchen wir die Basisinformationen wie bzw. Betriebssystem, IP, Netz, Anwendung.

 

Ein Ansatzpunkt bei ausgehender Kommunikation ist meist der Kommunikationsempfänger. Dort ist die Kommunikation eingehend und unterliegt dort deren Firewallregeln. Hier kann angesetzt werden.

Link zu diesem Kommentar

@Dukel Naja ich denke erhofft sich ein Sicherheitsplus wenn der Antivirenserver nicht mit Domänenkonten komprimittiert werden kann. Gab ja in letzter Zeit einige solcher positivien Meldungen insbesondere z.Bsp. für Backup-Ziele die ausserhalb der Domäne in einer Workgroup lagen die dann z.Bsp. nicht von vollständig von Ransomware verschlüsselt wurden weil kein Zugriff via den üblichen Domänen-Konten erfolgen konnte. Aber solche Maschinen müssen dann auch entsprechend abgeschottet werden damit es wirklich einen Vorteil hat.

 

 

@sd2019 Was meinst Du mit "Der Client wird über die Gerätesuche nicht gefunden"? Heisst das die Antivirenlösungen findet die Clients nicht? Der Hinweis mit DNS ist eher ein "Muss" wie ein "Soll". Du brauchst eine funktionierende Namensauflösung wenn deine Antiviren-Lösung nicht rein IP-Adressen basiert ist. Den Antivirenserver musst also im internen DNS-Server auch als Host eintragen. Der Antivirenserver muss die Hostst/Clients ebenfalls mit dem internen DNS-Server in der Domäne die IP-Adressen auflösen können. Insbesondere wenn alte Techniken zum Namensauflösung abgedreht wurden und auch abgedreht werden sollten.

 

Aber eben: Fragt sich was überhaupt die Antiviren-Lösung auf dem Server bereitstellen muss, was hin und her muss und warum der Server die Clients finden muss und nicht der Client sich melden soll und dann eingetragen wird.

--> Meine erste Anlaufstelle wäre hier der Hersteller der Lösung. Insbesondere bei Sicherheitstools hast selten eine Verbesserung sondern eher eine Verschlechterung der Sicherheits-Situtation wenn Du nicht Herstellerangaben befolgst.

Link zu diesem Kommentar

Stimmt. OOps.... Falsch gelesen :rolleyes: Aber da dürfte das gleiche gelten. Manuell in DNS registrieren damit die Namens-Auflösung funktioniert. Und auf einer Maschine manuell installieren ist ja jetzt auch nicht so dramatisch. Finde ich. Firewall aufmachen ist jendenfalls kaum zielführend für ein System das aus Sicherheitsgründen aus der Domäne raus ist. Da sollte eher nur genau das aktiviert sein, was effektiv zwingend gebraucht wird. =)

Link zu diesem Kommentar
Am 6.11.2021 um 14:24 schrieb MurdocX:

mit der richtigen Konfiguration ist es nicht nötig ein System außerhalb einer Domäne zu fahren. Mit den Hausmitteln geht alles. Das geht gefühlt hier immer unter ;-) 

Sicher? Gibts auch ne Wegleitung? Domain Admin kann man ja nicht wirklich effektiv beschneiden bzw. kann er sich ja selbst beglücken. Nen Exploit gibts auch von Zeit zu Zeit. Ob es dann wirklich hilft die Kiste nicht in der Domain zu haben steht wieder auf einem anderen Blatt =)

 

Allerdings wird es wohl je länger je mehr vorkommen das Kisten nicht Domain-Joined sind und Authentifizierung eher in Richtung Applikation geht. Zumindest wenn man so den Trend beobachtet mit eigenen Heimgeräten, oder sogar bei MS selbst mit Ihren Cloud-Geräterichtlinien etc. Man wird sehen. Dürfte die Verwaltung nicht unbedingt einfacher machen. =)

Link zu diesem Kommentar

 

Am 6.11.2021 um 14:24 schrieb MurdocX:

mit der richtigen Konfiguration ist es nicht nötig ein System außerhalb einer Domäne zu fahren. Mit den Hausmitteln geht alles. Das geht gefühlt hier immer unter ;-) 

Moin,

 

mit der richtigen Konfiguration ist es aber auch nicht nötig, viele Systeme ins AD aufzunehmen. Kommt immer darauf an, ob man Gott-Accounts haben möchte oder nicht.

 

"Geht alles" beinhaltet in letzter Konsequenz immer SIEM und jemanden, der die Ereignisse dort 24x7 nahezu in Echtzeit auswertet, denn nur so kannst Du ein Gott-Account aufhalten. Viele einzelne systemspezifische Admins (ohne password reuse eingerichtet ;-) ) zu knacken dauert schon deutlich länger und hinterlässt auch mehr Spuren.

 

Leider sind genau die Organisationen, die kein Geld für SIEM und SOC haben, diejenigen, welche auch kein Geld für ordentliches Configuration Management haben und deshalb das AD dafür missbrauchen, mit den bekannten Folgen. 

Link zu diesem Kommentar

Ich sehe schon, dass ich einfach zu allgemein und provokant geschrieben habe :-) Es gibt selten DEN Weg. Jetzt bin ich eine einfach Antwort schuldig der ich nicht nachkommen kann, weil es sie nicht gibt. ;-)

 

Am 8.11.2021 um 12:05 schrieb Weingeist:

Sicher? Gibts auch ne Wegleitung?

Naja, meinst du dann würde sie "einfach" und "schnell" sein? ;-) Microsoft hat dazu tatsächlich einige gute Dokumente zu Härtungen. Hatten wir dazu nicht zuletzt schon ein Thread dazu worum dazu ging? :-) 

 

Am 8.11.2021 um 12:39 schrieb cj_berlin:

Moin,

mit der richtigen Konfiguration ist es aber auch nicht nötig, viele Systeme ins AD aufzunehmen. Kommt immer darauf an, ob man Gott-Accounts haben möchte oder nicht.

Viele Wege führen nach Rom :-) Von SCT über verschiedene Admin-Kreise, User-Rollen und Netzen. Klar, bis zu SIEM. Dazwischen gibt es viel zu tun. Wichtig ist klarzustellen das das innerhalb des Netzwerks stattfindet und nicht auf einer "Firewall", die nur ein kleines Rädchen ist. Diese vielen Änderungen werden meist als "sehr Komplex" wahrgenommen, weil es das Troubleshooting nicht einfacher macht :-) 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...