Sophos Phish Threat: Absender, Domains und IPs erlauben

Sophos Phish Threat kann nur realistische Kampagnenergebnisse liefern, wenn Simulationen zugestellt werden und Benutzer die zugehörigen Phishing- und Trainingsseiten erreichen. Dafür müssen die von Sophos bereitgestellten Absender-Domains, IP-Adressen und Webziele an allen tatsächlich durchlaufenen Kontrollpunkten erlaubt werden. Eine pauschale Umgehung der E-Mail- oder Web-Sicherheit ist jedoch weder nötig noch sinnvoll.

Dieser Ablauf ist anbieterneutral. Er gilt für vorgelagerte Mail-Gateways, Mail Transfer Agents, Secure Web Gateways, Proxys, Firewalls, DNS- und URL-Filter sowie Produkte, die Links oder Anhänge automatisch untersuchen. Die produktspezifischen Schritte stehen in den Zustellungsanleitungen für Microsoft 365 und Google Workspace.

Aktuelle Werte in Sophos Fusion (ehemals Sophos Central) ermitteln

Die verbindliche Liste wird im betroffenen Sophos-Central-Tenant abgerufen:

1. Auf das Symbol Global Settings klicken.
2. Products and Services > Sophos Phish Threat öffnen.
3. Sending domains and IPs anklicken.
4. Alle angezeigten Absender-Domains, IP-Adressen und Webziele mit Abrufdatum dokumentieren.

Die regionalen Sophos Mailflow-IP-Adressen gehören nicht pauschal in die Phish-Threat-Allowlist. Sie werden nur für die automatisch eingerichteten Microsoft-365-Mailflow-Connectoren beziehungsweise für deren Wiederherstellung nach Konfigurationsänderungen verwendet. Solche Netze werden deshalb ausschliesslich im Rahmen der dokumentierten Mailflow-Connector-Konfiguration und nur für die verwendete Region eingetragen – nicht vorsorglich in vorgelagerten Gateways, Proxys oder Webfiltern.

Die Liste kann verschiedene Funktionen enthalten:

• IP-Adressen und Domains für den Versand der Kampagnen-E-Mails,
• Absender- oder Return-Path-Domains,
• Tracking- und Weiterleitungsziele für Klickmessungen,
• Domains für simulierte Phishing- oder Anmeldeseiten,
• Trainingsseiten und weitere für den Kampagnenablauf benötigte Webziele.

Phish-Threat-Links können über das von Sophos dokumentierte AWS-Tracking-Ziel awstrack.me weiterleiten. Eine solche Weiterleitung ist für die Klickmessung erwartbar. Welche Hosts tatsächlich benötigt werden, wird vor dem Pilotversand mit der aktuellen Sophos-Liste und den Zielen der konkreten Kampagne abgeglichen. Zusätzliche Subdomains werden nicht ohne einen dort oder in der Produktdokumentation nachgewiesenen Bedarf freigegeben.

Datenfluss vor der Freigabe aufnehmen

Allowlisting erfolgt pro Kontrollpunkt, nicht nur am letzten Mailserver. Zuerst wird der reale Weg einer Testnachricht und eines Testklicks dokumentiert:

1. Sophos Phish Threat versendet die Simulation.
2. Ein vorgeschalteter Cloud-Filter, Secure Email Gateway oder MTA nimmt die Nachricht an.
3. Weitere Anti-Spam-, Anti-Phishing-, Sandbox- oder Link-Analyse-Dienste verarbeiten sie.
4. Das Zielsystem stellt sie dem Postfach zu.
5. Beim Klick durchläuft der Benutzer DNS-Filter, Proxy, Secure Web Gateway, Firewall und gegebenenfalls Browser- oder Endpoint-Schutz.
6. Tracking-, Phishing- und Trainingsseiten senden die Ereignisse an Phish Threat zurück.

Für jeden Schritt werden Produkt, Regelinhaber, benötigter Wert, gewünschte Ausnahme, Ablauf- oder Review-Datum und Rückfallweg festgehalten. Befinden sich mehrere Filter hintereinander, muss jeder relevante Filter berücksichtigt werden. Eine Freigabe nur im Zielpostfach behebt keine Blockierung am vorgelagerten Gateway.

Allowlist mit möglichst engem Umfang umsetzen

Die Regel wird nur so breit angelegt, wie es für die Simulation technisch erforderlich ist. Bevorzugt werden exakte IP-Adressen oder Hostnamen, die aktuelle Phish-Threat-Liste und die vorgesehenen Testempfänger. Eine vollständige Domain, ein Wildcard-Muster oder eine globale Scanner-Ausnahme wird nur verwendet, wenn die Kampagnenkonfiguration beziehungsweise das Produkt keine engere Regel zulässt.

Manche Produkte unterscheiden zwischen Zustellung, Spam-Bewertung, URL-Umschreibung, Time-of-Click-Prüfung, Attachment-Sandboxing und Webzugriff. Eine einzelne «Allow»-Regel deckt diese Funktionen nicht automatisch ab. Umgekehrt darf eine Freigabe für die E-Mail-Zustellung nicht unbeabsichtigt alle Dateien oder URLs desselben Absenders von jeder Prüfung ausnehmen.

Variable Hosts nur bei nachgewiesenem Bedarf erlauben

Zunächst werden nur die in Sophos Fusion beziehungsweise der Produktdokumentation ausgewiesenen und in der Kampagne verwendeten Hosts einzeln aufgenommen. Verwendet ein konkretes Produkt- oder Kampagnenziel nachweislich variable Hosts und lässt sich die Freigabe technisch nicht auf exakte Hostnamen begrenzen, kann ein Wildcard erforderlich sein. Dann gelten zusätzliche Kontrollen:

• Wildcard nur unterhalb der von Sophos angezeigten Basisdomain setzen,
• nicht die gesamte übergeordnete Provider-Domain erlauben,
• Regel auf Phish-Threat-Verkehr und wenn möglich auf Pilotempfänger begrenzen,
• Verantwortlichen und Review-Datum dokumentieren,
• vor jeder neuen Kampagnenvorlage prüfen, ob ein zusätzlicher Host verwendet wird.

Eine sehr breite Freigabe wie eine komplette gemeinsam genutzte Cloud- oder Versandplattform erhöht das Risiko, fremden Verkehr zuzulassen. Wenn ein Produkt den benötigten engen Scope nicht abbilden kann, wird dieses Restrisiko vor der Änderung akzeptiert oder ein anderer Zustellungsweg gewählt.

False Clicks und automatisch geöffnete Anhänge verhindern

E-Mail-Sicherheitsprodukte prüfen Nachrichten häufig, indem sie URLs aufrufen oder Anhänge in einer Sandbox öffnen. Phish Threat kann einen solchen Abruf als Benutzeraktion werten. Das Ergebnis sind vermeintliche Klicks oder geöffnete Anhänge, obwohl der Empfänger die Nachricht noch nicht bearbeitet hat.

Typische Hinweise auf einen Scanner statt eines Benutzers sind:

• Ereignisse entstehen vor oder unmittelbar bei der Zustellung,
• viele Empfänger zeigen fast gleichzeitig dieselbe Aktion,
• Quelladressen oder User-Agents gehören zum Sicherheitsdienst,
• mehrere Links derselben Nachricht werden in kurzer Folge geöffnet,
• das Muster lässt sich mit einer frisch versendeten Pilotnachricht reproduzieren.

Die Korrektur erfolgt am verursachenden Scanner: Die aktuellen Phish-Threat-IP-Adressen und -Domains werden in dessen vorgesehene Liste für autorisierte Phishing-Simulationen oder gezielte Scan-Ausnahmen aufgenommen. Die Ausnahme muss sowohl zur erkannten Quelle als auch zur betroffenen Scan-Funktion passen. Nur eine Absenderadresse zu erlauben reicht nicht, wenn der Dienst unabhängig davon jede URL in einer Sandbox öffnet.

Fehlende Klickereignisse haben oft die gegenteilige Ursache. Tracking-Ziele können durch Secure Web Gateways, DNS-Filter oder Browser-Erweiterungen wie Werbeblocker blockiert werden. Deshalb wird bei fehlender Telemetrie nicht sofort die Kampagne neu gestartet, sondern zuerst die Redirect-Kette im Browser sowie Proxy-, DNS- und Endpoint-Logs geprüft.

Microsoft-365-Bypass-Header nur als Legacy-Ausnahme

Ältere Anleitungen verwenden Transportregeln mit den Headern X-MS-Exchange-Organization-SkipSafeLinksProcessing oder X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Solche Regeln sind nicht die Baseline für eine neue Einrichtung. Bei SMTP-basierter Zustellung durch die Microsoft-365-Transportpipeline ist dafür die Advanced Delivery Policy von Microsoft vorgesehen. Sophos empfiehlt für neue Einrichtungen dagegen M365 Direct Delivery; dieser Zustellungsweg umgeht die Transportpipeline, sodass Advanced Delivery darauf nicht angewendet wird. Die konkrete Microsoft-365-Konfiguration muss nach der aktuellen Sophos-Anleitung für den gewählten Zustellungsweg erfolgen und ist nicht Bestandteil dieses Artikels.

Legacy-Header kommen nur infrage, wenn eine bestehende Umgebung sie nachweislich noch benötigt, der aktuelle Supportstand geprüft wurde und ein genehmigter Change mit engem IP-/Domain-Scope vorliegt. Regelpriorität, Wirkung und Sicherheitsfolgen müssen separat getestet werden. Alte Headerregeln werden nicht zusätzlich «vorsorglich» neben einer aktuellen Simulationsfreigabe betrieben.

Pilotkampagne validieren

Zuerst wird eine kleine Pilotgruppe mit kontrollierten Testkonten verwendet. Sie sollte mindestens ein Postfach pro relevantem Zustellungsweg, Richtliniengruppe und Standort enthalten. Der Test deckt eine Nachricht mit Link und – falls betrieblich genutzt – eine Kampagne mit Anhang und Training ab.

Vor dem Versand werden Zeitstempel, Kampagnen-ID, Empfänger, erwarteter Absender, verwendete Domain und die geänderten Regel-IDs dokumentiert. Danach wird geprüft:

1. Das Gateway nimmt die Nachricht an und liefert sie genau einmal an das erwartete Postfach.
2. Die tatsächlich für den geplanten Regelmatch verwendeten Werte stimmen mit der aktuellen Sophos-Liste überein: die passende sichtbare From-Domain oder Envelope-Sender-/Return-Path-Domain und, falls die Regel IP-basiert ist, die vom prüfenden Gateway als Verbindungspartner protokollierte Quell-IP des sendenden SMTP-Systems. Diese Felder werden getrennt geprüft; die IP des empfangenden Servers ist kein Absender-IP-Match.
3. Die Nachricht landet weder in Quarantäne noch unerwartet im Junk-Ordner.
4. Vor einer Benutzeraktion erscheint in Phish Threat kein Klick- oder Anhangereignis.
5. Ein kontrollierter Benutzerklick öffnet die erwartete Redirect-, Simulations- oder Trainingsseite.
6. Genau diese Aktion erscheint mit plausibler Zeit im Kampagnenergebnis.
7. Proxy-, Firewall-, DNS- und Scanner-Logs zeigen die erwartete Regel, aber keine unnötig breite Umgehung.
8. Eine normale externe Testnachricht und ein nicht freigegebenes Webziel werden weiterhin nach den bestehenden Sicherheitsrichtlinien geprüft.

Erfolg bedeutet nicht nur «E-Mail angekommen». Zustellung, unverfälschte Kampagnenmessung, erreichbare Webziele und weiterhin wirksame Sicherheitskontrollen müssen gemeinsam bestätigt sein. Erst danach wird die Regel auf die vorgesehene Empfängergruppe erweitert.

Fehler systematisch eingrenzen

Bei fehlender Zustellung wird vom ersten Annahmepunkt nach innen geprüft: SMTP-Log, vorgelagertes Gateway, Quarantäne, nachgelagerte Transportregel und Zielpostfach. Der SMTP-Fehler beziehungsweise das Produkturteil zeigt, an welcher Stelle die Nachricht abgewiesen wurde. Zusätzliche breite Ausnahmen ohne diesen Nachweis erschweren die Ursachenanalyse.

Bei falschen Klicks wird dagegen die Zeitachse vom Versand bis zur Zustellung verglichen. Ein reproduzierbarer automatischer Abruf wird anhand von Scanner-Logs, Quell-IP und User-Agent dem verursachenden Produkt zugeordnet. Bei nicht erfassten echten Klicks werden DNS-Auflösung, Proxyentscheidung, TLS-Verbindung, Redirects und Browser-Erweiterungen geprüft.

Wenn die Ursache unklar bleibt, wird die Pilotkampagne gestoppt. Eine Ausnahme darf nicht schrittweise immer breiter gemacht werden, bis die Zustellung zufällig funktioniert.

Änderungen zurücknehmen und laufend pflegen

Vor der Umsetzung wird für jede Regel ein Rollback festgelegt: vorheriger Zustand, Regel-ID, Export oder Screenshot, verantwortliche Person und Reihenfolge der Rücknahme. Bei unerwarteter Zustellung fremder Nachrichten, einer zu breiten Sicherheitsumgehung, auffälligen Proxyzugriffen oder weiterhin verfälschten Kampagnendaten wird die Änderung deaktiviert beziehungsweise auf den letzten geprüften Stand zurückgesetzt. Anschliessend werden Mail- und Weblogs erneut kontrolliert.

Für den laufenden Betrieb gelten folgende Mindestkontrollen:

• aktuelle Werte vor jeder grösseren Kampagne mit Sophos Fusion vergleichen,
• Regeln nach Produkt-, Routing- oder Providerwechsel erneut testen,
• Wildcards und globale Ausnahmen regelmässig auf einen engeren Scope prüfen,
• nicht mehr benötigte Domains, IPs und Legacy-Regeln entfernen,
• Review-Datum, Eigentümer und technische Begründung an jeder Ausnahme hinterlegen,
• nach Änderungen immer eine Pilotkampagne ohne automatischen False Click durchführen.

FAQ