Category Archives: Technischer Blog

Verbindungsprobleme wegen Ethernet Collisions

Comment

ethernet-errors-und-collisionsIn einigen Supportfällen der Vergangenheit wurde zum Beispiel über Download langsam (oder fehlschlagend) bzw. VPN-Verbindung instabil geklagt. Als Ursache konnte jeweils eine Inkompatibilität auf Ethernet-Ebene zwischen der WatchGuard Firebox und – entweder dem vorgelagerten Übergabe-Router des Internet-Providers (im Regelfall an eth0) – oder dem internen Netzwerk-Switch (im Regelfall an eth1) lokalisiert werden, wodurch jeweils Ethernet Errors bzw. Ethernet Collisions auftraten.

Öffnen Sie den WSM, dann den Firebox System Manager. Auf der Registerkarte System Status scrollen Sie dann herunter, bis Sie den Abschnitt “Interfaces” finden. Grundsätzlich sollten die Ethernet Errors und Collisions auf allen Interfaces dauerhaft auf Null bleiben. Laufen die Werte hoch, haben Sie ein Problem.

WatchGuard empfiehlt, die Netzwerk-Interfaces an der Firebox auf Auto Negotiation (Auto-Sensing) zu belassen. Insofern sollte zunächst das Interface auf dem Router oder (managebaren) Switch manuell auf einen festen Wert eingestellt werden, um eine Kombination zu finden, die keine Errors und Collisions produziert. Gelegentlich hilft auch der Austausch des Netzwerkkabels! Bei den aktuellen Supportfällen handelte es sich jeweils um eine Company Connect Leitung der Telekom / T-Systems mit einem Cisco als Übergaberouter. Nach einer Störungsmeldung bei der Telekom dauerte es ca. 10 Minuten, bis die Kollegen dort ihren Router per Fernzugriff umkonfiguriert hatten – in der Regel wird der LAN-Port des ISP-Routers auf einen festen Wert von z.B. 100 Mbit Full Duplex gesetzt – und der Spuk mit den Errors und Collisions ein Ende hatte… 🙂

ethernet-collisions-x-edge-e-seriesHier noch ein historischer Screenshot einer Firebox X Edge e-series mit Softwareversion 10.x, bei der sich die Ethernet Statistik bei System Status > Interfaces befand. Im Screenshot ist erkennbar, dass Ethernet Collisions auftreten.

Dieser Artikel wurde erstmals am 22.12.2008 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

BOVPN Notification einschalten

Comment

Logging

Eine WatchGuard Firebox / XTM speichert lokal immer nur die letzten Minuten des Traffic Logs. Wenn Logging Informationen über einen längeren Zeitraum aufbewahrt werden sollen/müssen – und wenn die Alarm-Funktion (Notification) genutzt werden soll – muss ein separater WatchGuard Log Server bereitgestellt werden, zu dem die WatchGuard Box die Logmeldungen schicken kann. Die aktuelle und empfohlene Variante ist der Einsatz eines kostenfreien WatchGuard Dimension Servers, der als fertige virtuelle Appliance für VMware ESXi und Microsoft Hyper-V Umgebungen bereitgestellt wird. Wenn keine Virtualisierungsplattform vorhanden ist, können alternativ auch die althergebrachten Logging- und Reporting-Dienste des “WatchGuard System Managers” auf einem Windows Server verwendet werden. Interessant in diesem Zusammenhang ist auch folgender HOWTO Artikel, der die Bereitstellung eines “WatchGuard Dimension Servers auf einem kostengünstigen Intel NUC (Mini-PC) beschreibt.

Notification

Wenn eine WatchGuard Firebox / XTM an einen Logging Server angeschlossen und dieser korrekt konfiguriert ist, können für viele unterschiedliche Ereignisse auf der Firewall Notifications (Benachrichtigungen) erzeugt und per E-Mail an den Firewall-Administrator oder einen Support-Alias verschickt werden. Wichtig: Der Versand der Notification E-Mails erfolgt vom Logging Server aus – die Firewall liefert über das laufende Logging lediglich das Triggersignal dazu!

Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification:

bovpn-notification-1   bovpn-notification-2

Dieser Artikel wurde erstmals am 13.01.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

Feature Key vor Software Update aktualisieren

2 Comments

feature-key-livesecurityBevor man auf einer WatchGuard Firebox / XTM ein Software Upgrade (Fireware XTM) installiert, sollte man sicherstellen, dass auf der Firebox ein aktueller Feature Key (Lizenzdatei) vorhanden ist, der dies überhaupt zulässt. Ist nämlich die LiveSecurity (Standard Support) abgelaufen, verweigert sich die Firebox mit einer Fehlermeldung! Ob bzw. wie lange die Live Security (Standard Support) noch gültig ist, sieht man unter anderem im WSM > Policy Manager unter Setup > Feature Keys… Steht dort in rot “Expired”, braucht man gar nicht versuchen, die Arbeiten fortzusetzen. Stattdessen muss zunächst dafür gesorgt werden, dass wieder ein Feature Key mit gültiger Live Security vorhanden ist.

Wichtig: Wenn Sie der Meinung sind, dass Sie die LiveSecurity bereits verlängert haben, überprüfen Sie bitte in Ihrem Account auf der WatchGuard Website das dort für die Seriennummer angezeigte Ablaufdatum. Möglicherweise müssen Sie nur noch den aktuellen Feature Key eben dort herunterladen und genau in dem hier gezeigten Untermenü auf die WatchGuard hochladen (Save to Firebox nicht vergessen!). Bei dieser Gelegenheit können Sie auch das Häkchen setzen für Enable automatic feature key synchronization, damit die Firebox künftig selbständig mitbekommt, wenn Lizenzverlängerungen vorgenommen wurden. Liegt der neue Feature Key vor, muss dieser noch mit der alten Softwareversion importiert und auf die Firebox hochgeladen werden. Erst danach sollte über den Policy Manager der reguläre Update-Prozess gestartet werden: File > Upgrade…

Möglicherweise erforderliche Lizenzverlängerungen (Renewals) kauft man bei dem WatchGuard-Partner seines Vertrauens, gerne hier im Shop. 🙂

Dieser Artikel wurde erstmals am 28.01.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

Fireware XTM Installer zweimal starten

Comment

fireware-xtm-installer-zweimal-startenBisweilen kommt es vor, dass Software Releases der Fireware XTM durch Maintenance Updates ersetzt werden, die die gleiche Versionsnummer tragen (Beispiel: Fireware XTM 11.10.2 Update 1). Wenn aber bereits die ursprüngliche Version (Beispiel: Fireware XTM 11.10.2 ohne Update 1) auf dem Windows-PC installiert ist und dann der Installer des etwas neueren Builds (aber mit gleicher Versionsnummer) startet, erscheint zunächst die Meldung “Remove this program from your computer”. Diese Meldung verwundert zunächst: Warum soll etwas deinstalliert werden? – Es soll doch etwas installiert werden… Bestätigen Sie die Abfrage. Nun wird zunächst der ältere Build deinstalliert! Rufen Sie anschließend den Fireware XTM Installer einfach ein zweites Mal auf. Dann wird die neue Fireware XTM Version auch tatsächlich installiert…

Dieser Artikel wurde erstmals am 30.01.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

Funktionsweise des WatchGuard Firebox Regelwerks

Comment

Die WatchGuard Firewall prüft jede neu anstehende Verbindung von einem Host auf der einen Seite der Firewall zu einem Host auf der anderen Seite der Firewall. Dabei werden zunächst die Header der IP-Pakete untersucht: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, verwendetes Protokoll (TCP, UDP, ICMP etc.). Die Firewall durchforstet nun das Regelwerk sequentiell “von oben nach unten” (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).
Nacheinander wird jede einzelne Regel geprüft, ob sie die o.g. Kriterien erfüllt – so lange bis der erste “Treffer” gefunden wird. Nur diese Regel wird auch ausgeführt. Gibt es “weiter hinten” im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht/ausgeführt. Wird eine passende Regel gefunden, wird die Verbindung authentisiert und (bei TCP) in die TCP Session Table der Firewall eingetragen. Nachfolgende Pakete in der gleichen TCP-Verbindung werden dann automatisch von der Firewall durchgelassen und nicht noch einmal aufs Neue authentisiert (anders bei Application Proxy Regeln, die eine zusätzliche Kontrolle des Inhalts vornehmen).

Ganz am Ende des Regelwerks steht eine unsichtbare Deny Regel. Jeder Datenverkehr, der nicht ausdrücklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von außen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein Unhandled Internal Packet oder einUnhandled External Packet.

Warum werden die Unhandled Packets angezeigt?

Weil im Policy Manager bei Setup > Default Threat Protection > Deafult Packet Handling > Logging das Häkchen “Send Log message” bei den Kategorien “Unhandled Internal Packet” und “Unhandled External Packet” gesetzt ist. Das Logging könnte zwar durch Entfernen des Häkchens ausgeschaltet werden – das ist aber keine gute Idee (bessere Idee weiter unten :-). Der Traffic Monitor und die Unhandled Packets sind ein extrem wichtiges und hochinteressantes Tool, um Fehlverhalten von Maschinen bzw. Fehlkonfigurationen im lokalen Netzwerk aufzudecken und abzustellen! Die Anzeige der Denied Packets kann der Administrator auch sehr gut nutzen, um den Bedarf für neue Regeln zu erkennen und wie diese auszusehen haben.

Das Default Regelwerk und die globale Outgoing-Regel

Der Quick Setup Wizard erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip sämtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zulässt – und sämtlichen eingehenden Verkehr (incoming) verbietet.
Gewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zulässig ist und diesen auf Maschinen- und/oder User-Ebene auf das absolute Minimum beschränken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie möglich einschränkt. Ein gutes Firewall-Regelwerk wächst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das schöne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultmäßig vorhandeneOutgoing-Regel auf disabled gesetzt oder ganz gelöscht wird. Denn: das Regelwerk wird “von oben nach unten” abgearbeitet, der erste Treffer zählt. Solange “unten” die globale Outgoing-Regel steht, nützen die Einschränkungen weiter “oben” nichts. Der Verkehr würde trotzdem über die Outgoing-Regel rausgehen, also weg damit!

Anzeige von bestimmten Unhandled Packets unterdrücken

Bisweilen ärgert man sich doch über die Anzeige von Unhandled Packets. Eventuell kann man die Ursache dafür einfach nicht abstellen usw. Bei der Lösung hilft nun das bisher Gesagte: das unzulässige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel für diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks hängen.
Der Trick besteht nun einfach darin, eine explizite Firewall-Regel zu bauen, die den Verkehr genau beschreibt (siehe oben: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll), aber verbietet (“Denied”) – und das Logging ausschaltet. Der lästige Verkehr taucht künftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:

Konfigurationsbeispiel: HostWatch Namensauflösung (Port 137/udp) unterdrücken

Properties > Logging

Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel für den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen früher geprüft. Das kennen wir: ein explizites Verbot ist mächtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsmöglichkeit aus Denied- und Allow-Regeln auch ganz gerne so: Ping.Allow von Any nach Any -und- Ping.Denied von Any-External nach Firebox. Damit kann innerhalb des lokalen Netzwerks/VPN fröhlich hin- und hergepingt werden – auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn’s stört, kann für die Denied-Regel natürlich auch das Logging ausgeschaltet werden…

IKE Keep Alive und Dead Peer Detection (DPD)

Comment

Die Kernaussage vorweg: Steigern Sie die Stabilität Ihrer BOVPN Tunnel, indem Sie IKE Keep Alive –ODER– Dead Peer Detection (DPD) verwenden – aber nicht beides zusammen! Branch Office VPN Tunnel sind im Regelfall darauf ausgerichtet, möglichst 24 Stunden am Tag voll verfügbar zu sein (always on). Brechen Tunnel weg, liegt es meist an:

  • Ein oder beide Endpunkte haben eine instabile Internet-Anbindung, hohe Latenzzeiten oder Paketverluste. In meinem Artikel Verbindungsprobleme wegen Ethernet Collisions bin ich darauf bereits einmal eingegangen.
  • Veraltete Software-Stände oder Kompatibilitäts-Probleme (möglichst immer die aktuelle Software-Version einsetzen, sowohl auf WatchGuard Firebox Produkten als auch auf VPN Devices von Fremdherstellern).
  • Kein Traffic im VPN-Tunnel. Tunnel ohne Traffic tendieren dazu, instabil zu werden.

ike-keep-alive-und-dpd-dead-peer-detection

Die WatchGuard Firebox / XTM kennt mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen:

Bei IKE Keep Alive handelt es sich um ein WatchGuard-proprietäres Verfahren. Dieses sollte nur genau dann eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen und die Verwendung von DPD nicht gewünscht ist!

Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Wenn kein sonstiger Tunnel Traffic fließt, erzeugt der eine VPN-Endpunkt einen DPD-Request, der von der VPN-Gegenstelle mit einem DPD-Acknowledge beantwortet werden muss. Geschieht das nicht rechtzeitig innerhalb der eingestellten Settings (Default für DPD: 20 Sekunden, max. 5 Versuche) => 5 x 20 Sekunden plus die ursprünglichen 20 Sekunden => 120 Sekunden => 2 Minuten, dann geht der VPN-Endpunkt davon aus, dass die VPN-Gegenstelle “dead” ist, verwirft die SAs und startet die Neuaushandlung von Phase 1 und Phase 2. Hieraus geht auch hervor, dass DPD eben auf BEIDEN VPN-Endpunkten korrekt aktiviert und konfiguriert sein muss, denn sonst bewirkt diese Funktion das genaue Gegenteil: Statt dass der Tunnel über einen langen Zeitraum stabil bleibt, wird er im Extremfall alle 2 Minuten unterbrochen und neu ausgehandelt.

Es wird empfohlen, jedoch nur genau EIN Verfahren einzusetzen! Verwenden Sie IKE Keep Alive und DPD NICHT GLEICHZEITIG, dies bewirkt genau das Gegenteil: Wenn beide Verfahren aktiviert sind und ein Verfahren eine Phase 1 Renegotiation auslöst, erkennt das andere Verfahren den Tunnel als down und startet seinerseits eine zweite Phase 1. So entsteht ein Konflikt mit der gerade zuvor ausgehandelten Phase 1 und die Verfahren spielen Ping-Pong.vpn-keep-alive-edge

Auf der alten WatchGuard Firebox X Edge gibt es alternativ noch VPN Keep Alive (VPN > VPN Keep Alive). Hier kann pro Tunnel eine IP-Adresse eines Hosts auf der anderen Seite des Tunnels eingetragen werden, der 24/7 läuft und auf ping antwortet (z.B. ein Server, ein managebarer Switch oder ersatzweise die IP-Adresse des Trusted Interface der dortigen Firewall bzw. VPN-Komponente).

Dieser Artikel wurde erstmals am 07.02.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

E-Mail-Sicherheit mit dem WatchGuard SMTP-Proxy

Comment

Der Application Proxy für SMTP (SMTP-Proxy) steht in allen WatchGuard Firebox XTM Software-Versionen zur Verfügung – auch schon in den ganz alten Versionen des WFS v7.x. Heute möchte ich auf ein paar Aspekte des Themas “E-Mail-Sicherheit” eingehen, die schon mit den Bordmitteln der WatchGuard Firebox (also ohne die optionalen WatchGuard Security Services) möglich sind. Voraussetzung für die nachfolgenden Überlegungen ist, dass Ihre Firma bzw. Organisation ihre eingehenden E-Mails per SMTP zugesendet bekommt – dass Sie also in der Regel einen richtigen Mailserver für Ihre Domain verwenden – und nicht wie im Privatumfeld verbreitet “Postfächer” bei einem externen Provider nutzen, die über POP3 oder IMAP abgefragt werden!

1. Einschränkung der erlaubten (Ziel-)E-Mail-Domains

smtp-proxy-address-rcpt-to

Spam-Versender versuchen häufig, schlecht abgesicherte Mailserver im Internet für Massenversendungen zu missbrauchen. Sie suchen so genannte Open Mail Relays. Das sind Mailserver, die erst einmal ALLE E-Mails annehmen – egal an welche Empfänger-Adresse sie gerichtet sind – und sich dann im nächsten Schritt um die korrekte Zustellung kümmern. Stellen Sie sich vor: IHR hauseigener Mailserver bekommt eine E-Mail zugeschickt, die an die Adresse blabla@blabla-domain.de gerichtet ist. Nun, diese Adresse kennt er nicht, weil Ihre eigene Domain eben anders heißt 🙂 Wenn Ihr Mailserver schlecht konfiguriert ist, nimmt er die E-Mail an und versucht dann unter “eigenem Namen” (!) die E-Mail an die tatsächliche Empfänger-Domain “blabla-domain.de” zuzustellen. Damit tritt jedoch IHR Mailserver als Spam-Versender in Erscheinung – nicht mehr der eigentliche Spam-Absender. Die Folge wird sein, dass IHR Mailserver auf einer Blacklist von Anti-Spam-Organisationen auftauchen wird. Viele andere Mailserver WELTWEIT werden dann künftig auch LEGITIME E-Mails von Ihnen ABLEHNEN oder im schlimmsten Fall ungesehen verwerfen!

Die beste Gegenmaßnahme ist natürlich: Sorgen Sie dafür, dass Ihr Mailserver korrekt konfiguriert ist – also nur E-Mails an genau die Domain(s) annimmt, für die er auch zuständig ist! Alternativ (oder besser: ergänzend dazu) können Sie auch den SMTP-Proxy der WatchGuard Firebox einsetzen. In den Properties gibt es das Untermenü “Address” und dort “Rcpt To”. Dort steht standardmäßig ein Stern * als allgemeine Wildcard für Allow. Wenn Sie den Stern durch Wildcards mit den Domain-Namen ersetzen, für die Ihr Mailserver die Mails annehmen soll – Beispiel: *@meinefirma.de, *@meinefirma.com – wird die WatchGuard Firebox auch nur noch derartige E-Mails zu Ihrem Mailserver durchlassen – ein wirksames Gegenmittel gegen ungewollten Missbrauch als Open Mail Relay.

2. Positiv-Liste (Whitelisting) aller existierenden E-Mail-Adressen in Ihrer Domain

Wenn auf Ihrem Mailserver nicht mehr als etwa 300 (verschiedene) E-Mail-Adressen liegen, sollten Sie erwägen, ALLE existierenden E-Mail-Adressen im SMTP-Proxy > Properties > Adress > Rcpt To einzupflegen. Die WatchGuard Firebox würde dann nur noch E-Mails an eben diese Adressen durchlassen – und könnte alle anderen E-Mails mit einer sauberen SMTP-Fehlermeldung “550 Mailbox Unavailable” ABLEHNEN (Deny).

smtp-proxy-address-rcpt-to-2

Warum ist das interessant und wichtig? Viele Spammer generieren Spam-Mails an willkürlich erzeugte E-Mail-Adressen (john@meinefirma.de, joe@meinefirma.de,…) in der Hoffnung, vielleicht eine existierende Adresse zu erwischen oder in einem Sammel-Postfach zu landen. Ein korrekt konfigurierter Mailserver müsste bei jeder unzustellbaren E-Mail einen Unzustellbarkeits-Bericht erzeugen (NDR, Non Delivery Report) und an den vermeintlichen (!) Absender schicken. Die Absende-E-Mail-Adresse ist im Spam-Umfeld jedoch meist genauso gefaked, existiert nicht oder der “echte” für die missbrauchte Domain zuständige Ziel-Mailserver verweigert die Annahme. Damit bleibt unser EIGENER Mailserver zunächst einmal auf dem ausgehenden Unzustellbarkeitsbericht sitzen! Das verstopft im Extremfall die Ausgangs-Warteschlangen (sprich Resourcen im Hauptspeicher, Festplatte) und kann sich durchaus auch zu einer DOS-Attacke (Denial of Service) ausweiten!
Wenn Ihr Mailserver aber von dem SMTP-Proxy der WatchGuard Firebox nur noch solche E-Mails vorgelegt bekommt, die er intern auch tatsächlich zustellen kann, gibt es eben keine unzustellbaren E-Mails mehr. Damit ist das Thema “unzustellbare Unzustellbarkeits-Berichte” vom Tisch und Ihr Mailserver freut sich über deutlich weniger Last! 🙂

Ob dieser Ansatz für Sie praktikabel ist, hängt von der Anzahl Ihrer existierenden E-Mail-Adressen und deren Wechsel-Häufigkeit ab. Ich kenne Installationen mit ca. 300 E-Mail-Adressen, bei denen vielleicht zwei oder drei Mal im Monat diese Liste nachgepflegt werden muss. Der Nutzen ist dann DEUTLICH höher als der administrative Aufwand. Leider findet kein dynamischer Abgleich per LDAP- oder Active Directory-Abfrage statt – die Liste muss HÄNDISCH nachgepflegt werden. Sie können die E-Mail-Adressen entweder einzeln über die GUI eingeben oder nutzen dafür einen XML-Editor, um fertig vorbereitete Tags mit Cut&Paste direkt in die Konfigurationsdatei einzubauen (Achtung: natürlich ist hierbei Vorsicht geboten!) Selbst bei 300 Adressen dauert die Eingabe über die GUI nicht besonders lange, wenn Sie z.B. den Domainnamen in die Zwischenablage legen, so dass Sie praktisch nur den Teil vor dem @-Zeichen eintippen müssen…

In diesem Screenshot werden noch zwei erweiterte Funktionen aufgezeigt. Durch einen Klick auf Change View oben rechts ändert sich die bisherige einfache Ansicht in die erweiterte Darstellung. Hier haben Sie die Möglichkeit, mit “Up” und “Down” auch die Reihenfolge festzulegen, in der die einzelnen Regeln abgearbeitet werden (jede E-Mail-Adresse ist praktisch eine eigene Regel). Außerdem können Sie hier mit der Rewrite-Funktion arbeiten, um einzelne Ziel-Adressen umzuschreiben. Wenn Sie hier mit einer Wildcard arbeiten, können Sie z.B. ein Sammel-Postfach für alle nicht vorher einzeln aufgeführten Adressen schaffen. Ich bin aber kein Freund von diesem Ansatz – ich lasse lieber unzustellbare E-Mails von der WatchGuard Firebox ABLEHNEN.

3. Von extern kommende E-Mails “aus der eigenen Domain” ablehnen

smtp-proxy-mail-from-deny-eigene-domainSehr häufig versuchen Spam-Versender, den Empfängern E-Mails als vertrauenswürdig unterzujubeln, die angeblich von einem Absender aus der eigenen Domain stammen. Oder sogar von der “eigenen” E-Mail-Adresse. Wie kann man sich per SMTP-Proxy wirkungsvoll davor schützen? Wir befinden uns hier ja im professionellen Umfeld und gehen wie eingangs geschildert davon aus, dass wir für unsere E-Mail-Domain einen eigenen Mailserver betreiben, der sich in unserem lokalen Netzwerk befindet und im Internet per DNS MX-Record bekannt ist. In einem solchen Szenario sitzen die E-Mail-Nutzer oftmals entweder alle im lokalen Netzwerk oder erhalten ihre E-Mails über gesicherte VPN-Verbindungen oder SSL-verschlüsselte E-Mail Push-Verfahren wie Microsoft ActiveSync oder Outlook Anywhere auf ihre Smartphones. Häufig kommt es gar nicht vor, dass von außen (über das Internet) legitime E-Mails per SMTP hereinkommen, die aus der eigenen Domain stammen! Seltene Ausnahmen sind z.B. gehostete Webserver, die E-Mails aus Kontaktformularen versenden und dabei einzelne Absende-Adressen z.B. formular@meinefirma.de verwenden. Oder wenn sich tatsächlich einzelne User per SMTP-Auth übers Internet am internen Mailserver anmelden, um darüber E-Mails zu versenden. Letzteres würde ich tunlichst so schnell wie möglich abstellen. Zu den Formularen kommen wir später.

Um zu verbieten, dass per SMTP von außen Mails eingehen, die behaupten, aus der eigenen Domain zu stammen, dann kann man das auch explizit auf der WatchGuard einstellen.
smtp-proxy-mail-from-allow
Hierzu bietet sich der Unterpunkt Address > Mail From in der SMTP Proxy Action an. Dort kann ich mit expliziten Allow und Deny Regeln steuern, von welchen Absende-Domains Mails angenommen werden sollen bzw. eben nicht. Genau hier wird die eigene Domain auf Deny gesetzt! Für den oben beschriebenen Fall des E-Mail-Formulars könnte sich anbieten, eine individuelle, kryptische Absendeadresse zu verwenden (Beispiel: formular-xyz-123@meinefirma.de statt formular@meinefirma.de), welche von Spammern nicht unbedingt sofort erraten werden kann, denn für diese Adressen muss ja eine “Allow” Ausnahme definiert werden. Ganz wichtig: zusätzlich muss noch die Wildcard * angelegt, auf Allow gesetzt und ganz ans Ende der Liste gestellt werden, sonst kommen gar keine Mails mehr von außen rein. Die korrekte Reihenfolge der Regeln wird über Change View und die Up / Down Schaltflächen eingestellt (vgl. Screenshot).

Kurze Fußnote zu den Web-Formularen und SMTP E-Mails: der versendende Web-/Mailserver sollte auch im DNS SPF Record Ihrer Domain berücksichtigt werden, denn sonst werden künftig immer häufiger solche Mails von den Empfängern nicht mehr angenommen…

Dieser Artikel wurde erstmals am 24.02.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

Lock / Unlock bei SMTP E-Mails

Comment

Der SMTP-proxy verfügt im Bereich Attachments sowohl bei Content Types als auch bei Filenames über die Optionen Allow, Lock, AV Scan, Strip, Drop undBlock im Pull-Down-Menü Actions to take. Wurde zur Steuerung von unerwünschten E-Mail-Anhängen vom Default Strip (Herausschneiden und Löschen) abgewichen und die Option Lock gewählt, werden Dateianhänge, auf die ausgewählten Kriterien passen, von der WatchGuard Firewall “ge-locked”.

Im Detail passiert folgendes: die Datei wird binärtechnisch leicht verändert, es werden ein paar Byte vor und hinter die Datei gehängt. Außerdem wird der Dateiname um die Endung .clk ergänzt (cloaked). Die Datei hängt aber nach wie vor an der eigentlichen E-Mail dran und erreicht auch das Postfach des Empfängers. Versucht nun der Empfänger, die Datei mit Doppelklick zu öffnen, schlägt dies fehl. Dies ist auch so beabsichtigt! An die E-Mail wird eine zusätzliche Textdatei angehängt, die die bei Deny Message definierte Fehlermeldung beinhaltet. Der Standardtext lautet: “The WatchGuard Firebox that protects your network has detected a message that may not be safe. […] Your network administrator can unlock this attachment.”Außerdem finden sich nähere Angaben über die Datei und den Grund.

Die Option Lock gibt es schon seit über zehn Jahren bei WatchGuard-Produkten. Die theoretische Denke dahinter ist auch genau so alt: der Empfänger speichere die ge-lockte Datei z.B. auf ein transportables Speichermedium (Diskette, USB-Stick) und gehe damit zu seinem Systemadministrator. Dieser starte in einer MSDOS-Eingabeaufforderung auf einem – separat vom lokalen Netzwerk stehenden und mit einer aktuellen lokalen Antivirus-Software ausgestatteten – PC das kleine Hilsprogrammunlock.exe, das sich im Verzeichnis C:\Programme\WatchGuard\wsm10.2\binbefindet und entpackt dadurch die .clk-Datei in den Urzustand, woraufhin sie mit der Antivirus-Software untersucht und bei Unbedenklichkeit an den eigentlichen Empfänger ausgehändigt werden kann. Abwandlungen in der einen oder anderen Form gestattet… 🙂

Auch das Gateway Antivirus-Subsystem kann die Option Lock nutzen, entweder wenn bereits tatsächlich ein Virus in der Datei gefunden wurde – oder wenn ein Scan Error aufgetreten ist, also die AV Engine die Datei nicht scannen konnte. Das ist übrigens auch dann der Fall, wenn die Datei verschlüsselt ist – und sei es nur eine ZIP-Datei, die mit einem Kennwort versehen wurde. Klar – eine verschlüsselte Datei kann erst dann auf Viren gescannt werden, wenn sie korrekt entschlüsselt wurde. In einem solchen Fall kann man natürlich der lokalen Antivirus-Software auf dem PC des Empfängers vertrauen und anstelle von Lock die Option Allow wählen – oder man nutzt die Option Lock und überläßt zumindest das Entpacken dem Administrator…

Wie Auto Negotiation auf HA Port abschalten?

Comment

In einem Hochverfügbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang “klassisch” per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL/Glasfasern verbundene Serverräume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuführung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische “Static IP” Konfiguration.

Für alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT über Switche, sondern DIREKT miteinander verbunden – mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und häufig zufällige Failovers ausgelöst wurden.

Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert für den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch “Auto-Sensing” eingestellt – auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde…

Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei für das entsprechende Interface der Wert für < auto-sensing > von 1 auf 0 geändert und die gewünschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschließend auch noch für diezweite Firebox manuell in deren Konfigurationsdatei geändert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.

Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell “nicht supported” und erfolgen auf “eigene Gefahr”.

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services(WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.