Jump to content

Schutz vor Web Bedrohungen KES11_KSC12 - wo ist exaktes log der geblockten Verbindungen


Go to solution Solved by alexcad,

Recommended Posts

Posted

Hallo,

 

Umgebung ist KSC12 Server mit KES11_6 Clients.

Die Komponente “Schutz vor Web Bedrohungen” ist überall aktiv.

Wir wissen wie man Ausnahmen setzt → das funktioniert auch.

 

Eine Spezialanwendung mit PKI Zertifikaten wird allerdings auch nach Aufnahme der Ziel - Site weiterhin von o. g. Komponente geblockt. Wenn wir “Schutz vor Web Bedrohungen” temporär abschalten funktioniert die Anwendung.

 

Frage:

In den “Berichten” & “Ereignissen” können wir weder im KSC, noch direkt am Client sehen

  1. warum Kaspersky diese / eine Site blockt
  2. welche Site Kaspersky blockt.

Um die Anwendung am Laufen zu halten müssen wir also wissen, welche Site geblockt wird.

Wo kann man sich im Kaspersky das EXAKTE Logfile oder ggf. Berichte ansehen, welche einem

Admin die geblockten Adressen anzeigen / verraten?

 

Vielen Dank für Ihre Hilfe,

VG

 

Posted

Hallo Khappa,

willkommen im Forum.

Frage: Hast du SSL-Inspection aktiv? Du findest das in der Richtlinie hier:
 

 

Wenn ja: Teste bitte mal ohne SSL-Inspection bzw. mit gesetzten Ausnahmen (vertrauenswürdige Adressen bzw. vertrauenswürdige Programme).

Grüße
Alex

Posted

Hallo Alex,

 

Danke für deine schnelle Hilfe.

Ohne den Haken für die SSL Prüfung geht es. Ist zumindest ein Workaround ohne die komplette

Komponente temp. deaktivieren zu müssen.

Kannst du mir verraten, wo ich generell genauere Logs der Komponenten sehe ( um die exakte Ziel - URL als Ausnahme definieren zu können welche geblockt wird)? Oder muss man für derartige Auswertungen vor einem gewünschten Vorgang erst ein Kaspersky Logging Modul oder ähnliches starten?

VG

  • Solution
Posted

Problem in deinem Fall ist ja: Das Modul “Schutz vor Web Bedrohungen” blockt nichts, daher wird auch nichts reportet. Nur die SSL-Inspection sorgt für eine Funktionsstörung der Anwendung.

Am ehesten hilft dir hier noch der Netzwerkmonitor auf einem System, auf dem sich das Problem nachstellen lässt.

 

Hier siehst du sehr präzise welche Anwendung über welche Ports wohin kommuniziert:
 


Hinweis: Im Netzwerkmonitor lassen sich bei deaktivierter Richtlinie sehr einfach lokal Programm- oder/und Paket-Regeln für die Firewall erstellen.

Nochmal zurück zur SSL- Inspection:
Das ist in Security-Kreisen ein strittiges Thema. Ein Aufbrechen der verschlüsselten Verbindung birgt immer auch Störungs-Potential, so wie in deinem Fall. Viele Verbindungen prüfen korrekter Weise, ob das Zertifikat noch übereinstimmt und verweigern die Kommunikation (z. B. vCenter). Damit sollen Man-in-the-Middle-Attacken verhindert werden - nichts anderes ist SSL-Inspection. 
Andererseits verspricht man sich durch das Scannen von SSL-Verbindungen ein mehr an Sicherheit, zumal ja heutzutage alle Web-Seiten über HTTPS erreichbar sind.

Meine Vorgehensweise: Wir diskutieren mit unseren Kunden diesen Punkt ausführlich und betrachten die Gesamt-Umgebung, vor allem bzgl. Security. In der Regel kommen wir zu dem Schluss die SSL-Inspection der KES zu deaktivieren. Oft gibt es ja auch schon eine Untersuchung von SSL-Verbindungen auf der Firewall/UTM. 
Und nach dem Modul “Schutz vor Web Bedrohungen” kommen ja noch einige andere Schutzmodule der KES, die im Ernstfall effektiv greifen.

Was auch eine Option ist: Über Richtlinien-Profile lassen sich Richtlinien-Einstellungen für ausgewählte Systeme regelbasiert abweichend konfigurieren.
Siehe dazu z. B. 

Link


Grüße
Alex​​​​​​​

Guest
This topic is now closed to further replies.


×
×
  • Create New...