ESA-Zentralisierung von Richtlinien, Virus und Outbreak-Quarantäne (PVO) kann nicht aktiviert werden

Einleitung

In diesem Dokument wird ein Problem beschrieben, bei dem die zentrale Richtlinie, der Virus- und der Outbreak-Quarantäne (PVO) nicht auf der Cisco Email Security Appliance (ESA) aktiviert werden kann, da die Schaltfläche "Aktivieren" deaktiviert ist und eine Lösung für das Problem bietet.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• So aktivieren Sie PVO auf der Security Management Appliance (SMA).
• Hinzufügen des PVO-Service zu jeder verwalteten ESA.
• Konfigurieren der Migration von PVO

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• SMA Version 8.1 und höher
• ESA Version 8.0 und höher

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Hintergrundinformationen

Nachrichten, die von bestimmten Filtern, Richtlinien und Scanvorgängen auf einer ESA verarbeitet werden, können in Quarantäne gestellt werden, um sie für weitere Aktionen vorübergehend in Quarantäne zu halten. In einigen Fällen scheint es, dass das PVO auf der ESA nicht aktiviert werden kann, obwohl es auf der SMA ordnungsgemäß konfiguriert wurde und der Migrations-Assistent verwendet wurde. Die Taste zum Aktivieren dieser Funktion auf der ESA ist in der Regel immer noch grau unterlegt, da die ESA keine Verbindung mit der SMA an Port 7025 herstellen kann.

Problem

Auf der ESA ist die Schaltfläche "Aktivieren" abgeblendet.

SMA zeigt an, dass der Service nicht aktiv ist und eine Aktion erforderlich ist

Lösung

Es gibt mehrere Szenarien, die hier beschrieben werden.

Szenario 1

Führen Sie auf der SMA den Befehl status in der CLI aus, um sicherzustellen, dass sich die Appliance im Online-Zustand befindet. Wenn die SMA offline ist, kann das PVO auf der ESA nicht aktiviert werden, da die Verbindung fehlschlägt.

sma.example.com> status

Enter "status detail" for more information.

Status as of:                  Mon Jul 21 11:57:38 2014 GMT
Up since:                      Mon Jul 21 11:07:04 2014 GMT (50m 34s)
Last counter reset:            Never
System status:                 Offline
Oldest Message:                No Messages

Wenn die SMA offline ist, führen Sie den Befehl resume aus, um sie wieder online zu bringen, wodurch cpq_listener gestartet wird.

sma.example.com> resume

Receiving resumed for euq_listener, cpq_listener.

Szenario 2

Nachdem Sie den Migrations-Assistenten auf der SMA verwendet haben, müssen Sie die Änderungen bestätigen. Die Schaltfläche [Enable...] auf der ESA bleibt deaktiviert, wenn Sie keine Änderungen bestätigen.

1. Melden Sie sich mit dem Administrator-Konto bei der SMA und der ESA an, nicht mit dem Operator (oder anderen Kontotypen) oder der Einrichtung, aber die Schaltfläche [Aktivieren...] ist auf der ESA-Seite abgeblendet.
   
   
2. Wählen Sie auf der SMA Management Appliance > Centralized Services > Policy, Virus and Outbreak Quarantines (Verwaltungs-Appliance > Zentrale Dienste > Richtlinien-, Virus- und Outbreak-Quarantänen).
   
   
3. Klicken Sie auf Migrationsassistent starten, und wählen Sie eine Migrationsmethode aus.
   
   
4. Senden und bestätigen Sie Ihre Änderungen.
   
   

Szenario 3

Wenn die ESA über den Befehl delivery yconfig mit einer Standardzustellungsschnittstelle konfiguriert wurde und wenn diese Standardschnittstelle keine Verbindung zur SMA hat, weil sie sich in einem anderen Subnetz befindet oder keine Route vorhanden ist, kann das PVO auf der ESA nicht aktiviert werden.

Hier ist eine ESA mit einer Standardschnittstelle für die Lieferung, die für die Schnittstelle In konfiguriert ist:

mx.example.com> deliveryconfig

Default interface to deliver mail: In

Hier ist ein ESA-Konnektivitätstest von Interface In zu SMA Port 7025:

mx.example.com> telnet

Please select which interface you want to telnet from.
1. Auto
2. In (192.168.1.1/24: mx.example.com)
3. Management (10.172.12.18/24: mgmt.example.com)
[1]> 2

Enter the remote hostname or IP address.
[]> 10.172.12.17

Enter the remote port.
[25]> 7025

Trying 10.172.12.17...
telnet: connect to address 10.172.12.17: Operation timed out
telnet: Unable to connect to remote host

Um dieses Problem zu beheben, konfigurieren Sie die Standardschnittstelle auf Auto (Automatisch), wobei die ESA automatisch die richtige Schnittstelle verwendet.

mx.example.com> deliveryconfig

Default interface to deliver mail: In

Choose the operation you want to perform:
- SETUP - Configure mail delivery.
[]> setup

Choose the default interface to deliver mail.
1. Auto
2. In (192.168.1.1/24: mx.example.com)
3. Management (10.172.12.18/24: mgmt.example.com)
[1]> 1

Szenario 4

Verbindungen zur zentralen Quarantäne sind standardmäßig mit Transport Layer Security (TLS) verschlüsselt. Wenn Sie die E-Mail-Protokolldatei auf der ESA überprüfen und nach Delivery Connection IDs (DCIDs) für Port 7025 auf der SMA suchen, werden Sie möglicherweise folgende TLS-Fehler finden:

Mon Apr 7 15:48:42 2014 Info: New SMTP DCID 3385734 interface 172.16.0.179
address 172.16.0.94 port 7025
Mon Apr 7 15:48:42 2014 Info: DCID 3385734 TLS failed: verify error: no certificate
from server
Mon Apr 7 15:48:42 2014 Info: DCID 3385734 TLS was required but could not be
successfully negotiated

Wenn Sie tlsverify auf der ESA-CLI ausführen, wird dasselbe angezeigt.

mx.example.com> tlsverify

Enter the TLS domain to verify against:
[]> the.cpq.host

Enter the destination host to connect to.  Append the port (example.com:26) if you are not
connecting on port 25:
[the.cpq.host]> 10.172.12.18:7025

Connecting to 10.172.12.18 on port 7025.
Connected to 10.172.12.18 from interface 10.172.12.17.
Checking TLS connection.
TLS connection established: protocol TLSv1, cipher ADH-CAMELLIA256-SHA.
Verifying peer certificate.
Certificate verification failed: no certificate from server.
TLS connection to 10.172.12.18 failed: verify error.
TLS was required but could not be successfully negotiated.

Failed to connect to [10.172.12.18].
TLS verification completed.

Auf dieser Grundlage führt die ADH-CAMELLIA256-SHA-Chiffre, die zur Verhandlung mit der SMA verwendet wird, dazu, dass die SMA kein Peer-Zertifikat präsentiert. Weitere Untersuchungen haben ergeben, dass alle ADH-Chiffren eine anonyme Authentifizierung verwenden, die kein Peer-Zertifikat bereitstellt. Die Lösung ist, anonyme Chiffren zu beseitigen. Ändern Sie dazu die Liste der ausgehenden Verschlüsselungen in HIGH:MEDIUM:ALL:-aNULL:-SSLv2.

mx.example.com> sslconfig

sslconfig settings:
  GUI HTTPS method:  sslv3tlsv1
  GUI HTTPS ciphers: RC4-SHA:RC4-MD5:ALL
  Inbound SMTP method:  sslv3tlsv1
  Inbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL
  Outbound SMTP method:  sslv3tlsv1
  Outbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL

Choose the operation you want to perform:
- GUI - Edit GUI HTTPS ssl settings.
- INBOUND - Edit Inbound SMTP ssl settings.
- OUTBOUND - Edit Outbound SMTP ssl settings.
- VERIFY - Verify and show ssl cipher list.
[]> OUTBOUND

Enter the outbound SMTP ssl method you want to use.
1. SSL v2.
2. SSL v3 
3. TLS v1 
4. SSL v2 and v3
5. SSL v3 and TLS v1
6. SSL v2, v3 and TLS v1
[5]> 

Enter the outbound SMTP ssl cipher you want to use.
[RC4-SHA:RC4-MD5:ALL]> HIGH:MEDIUM:ALL:-aNULL:-SSLv2

sslconfig settings:
  GUI HTTPS method:  sslv3tlsv1
  GUI HTTPS ciphers: RC4-SHA:RC4-MD5:ALL
  Inbound SMTP method:  sslv3tlsv1
  Inbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL
  Outbound SMTP method:  sslv3tlsv1
  Outbound SMTP ciphers: HIGH:MEDIUM:ALL:-aNULL:-SSLv2

Choose the operation you want to perform:
- GUI - Edit GUI HTTPS ssl settings.
- INBOUND - Edit Inbound SMTP ssl settings.
- OUTBOUND - Edit Outbound SMTP ssl settings.
- VERIFY - Verify and show ssl cipher list.
[]> 

mx.example.com> commit

Tipp: Fügen Sie außerdem -SSLv2 hinzu, da es sich hierbei ebenfalls um unsichere Verschlüsselungen handelt.

Szenario 5

Das PVO kann nicht aktiviert werden und zeigt diesen Fehlertyp an.

Unable to proceed with Centralized Policy, Virus and Outbreak Quarantines 
configuration as host1 and host2 in Cluster have content filters / DLP actions 
available at a level different from the cluster Level.

Die Fehlermeldung kann darauf hinweisen, dass auf einem der Hosts kein SvD-Feature-Schlüssel angewendet wurde und SvD deaktiviert ist. Die Lösung besteht darin, den fehlenden Feature-Schlüssel hinzuzufügen und SvD-Einstellungen anzuwenden, die mit denen auf dem Host identisch sind, auf den der Feature-Schlüssel angewendet wurde. Diese Feature-Schlüssel-Inkonsistenz hat möglicherweise den gleichen Effekt wie Outbreak-Filter, Sophos Antivirus und andere Feature-Schlüssel.

Szenario 6

Die Schaltfläche zum Aktivieren des PVO ist abgeblendet, wenn in einer Clusterkonfiguration eine Computer- oder Gruppenkonfiguration für Inhalte, Nachrichtenfilter, SvD und DMARC-Einstellungen vorhanden ist. Um dieses Problem zu lösen, müssen alle Nachrichten- und Content-Filter von der Computer- oder Gruppenebene auf die Cluster-Ebene sowie auf DLP- und DMARC-Einstellungen verschoben werden. Alternativ können Sie den Computer, der über eine Konfiguration auf Computerebene verfügt, vollständig aus dem Cluster entfernen. Geben Sie den CLI-Befehl clusterconfig > removemachine ein, und verbinden Sie ihn mit dem Cluster, um die Cluster-Konfiguration zu übernehmen.

Zugehörige Informationen

• Fehlerbehebung bei der Zustellung von und an die PVO-Quarantäne auf SMA
• Anforderungen für den PVO-Migrationsassistenten bei geclusterter ESA
• Technischer Support und Dokumentation für Cisco Systeme