Category Archives: Technischer Blog

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.

Command Line Interface (CLI) auf Port 4118 tcp

Comment

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung imKommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört.

Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).

Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen.

cli

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unterhttp://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

1 Comment

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird - also Firewall-Regeln verwendet werden, dieauf User-Basis greifen und nicht auf Maschinen-Basis - kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. 

Der beste Ansatz, dieses Verhalten zu umgehen, ist der Einsatz eines offiziellen Webserver SSL-Zertifikats, das aber kostenpflichtig ist und im Regelfall pro Jahr ebenfalls kostenpflichtig erneuert werden muss.

Alternativ dazu kann bei Vorhandensein einer (Windows) Active Directory Umgebung dort auch eine eigene (Windows-)Zertifizierungsstelle aufgesetzt und darüber ein eigenes Webserver-Zertifikat generiert werden. Computer, die Mitglied der Domäne sind, lernen dieses Zertifikat dann automatisch.

Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:

Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:

WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über "Import Certificate / CRL" auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: "Error: Error occurred while performing 'import certificate': certificate add error msg="Failed to import a certificate!! 6_982: certificate validation fail" add certificate". Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier:http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option"IPSec, Web Server, Other". Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate... > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglichGroß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Trade-Up / Migration auf neue WatchGuard Hardware

Comment

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Überhttps://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > ConfigurationEinstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

Multi-WAN und Policy Based Routing

Comment

Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, können bis zu vier Interfaces als External Interface konfiguriert werden. Hier können jeweils unterschiedliche Internet-Anschlüsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen überlastet ist, weil “zu viel” HTTP/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig Bandbreite für VPN-Anbindungen, E-Mail und andere unternehmenskritische Anwendungen übrig bleibt…
Statt einfach die Bandbreite der Standleitung für teuer Geld beim Provider hochsetzen zu lassen, kann auch darüber nachgedacht werden, einen – deutlich billigeren – ADSL, VDSL oder Kabel-TV-Anschluss als zweiten Internet-Anschluss an die gleiche WatchGuard anzubinden und über das Firewall-Regelwerk festzulegen, dass der typische HTTP und HTTPS Traffic über eben diese billigere DSL-Leitung geführt wird (Policy Based Routing, PBR). Damit wird die (teure) Standleitung von eben diesem TrafficENTLASTET.

Die unternehmenskritischen Services können so evtl. auch auf längere Sicht auf dem bisherigen Stand zu deutlich geringeren laufenden Kosten versorgt werden.

Wenn nun mindestens ein zweites Interface der WatchGuard als “External” konfiguriert wird, sind zusätzliche Einstellungen erforderlich, ohne die das gewünschte Verhalten eventuell nicht zum Tragen kommt! Insbesondere muss im Policy Manager unter Network > Configuration die Registerkarte Multi-WAN beachtet werden, die bei Verwendung nur eines einzelnen externen Interfaces “ausgegraut” war.
Hier wähle ich in der Regel als Default-Verhalten im Multi-WAN-Betrieb anstelle des voreingestellten Verfahrens “Routing Table” das Verfahren “Failover” aus und aktiviere hinter dem Button “Configure” die am typischen Multi-WAN-Betrieb beteiligten externen Interfaces (die Zahlen in Klammern entsprechen der Interface-Nummer auf der WatchGuard: z.B. 0=eth0, 6=eth6):

Die angezeigte Reihenfolge der Interfaces entspricht auch dem tatsächlichen Verhalten der WatchGuard Firebox für ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gemäß dieser Liste von oben nach unten bedient. Will heißen: Wenn das ganz oben aufgeführte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das nächste Interface in der Liste verwendet…

Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird über die Registerkarte Multi-WAN gesteuert:

Für jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verfügbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgeführten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardmäßig das Default Gateway des jeweiligen Interfaces). Wenn die angepingte IP-Adresse (3+1) = 4 x 15 => 60 Sekunden) nicht antwortet, wird das Interface auf “INACTIVE” gesetzt. Kommen wieder drei aufeinanderfolgende Antworten im Abstand von 15 Sekunden, wird das Interface wieder auf “ACTIVE” gesetzt und nimmt am Multi-WAN-Verfahren teil.

Daraus ergeben sich zwei Problematiken:

    • Problem 1 (Szenario Standleitung) => “Wo befindet sich das Default Gateway einer Standleitung?” Antwort: “Das ist der Übergaberouter des ISP, der sich in der Regel beim Kunden vor Ort befindet und per Kabel direkt an der WatchGuard angeschlossen ist”. Wenn nun eben dieser Router auf “ping” antwortet: Ist das eine zuverlässige Aussage darüber, ob nun die eigentliche Internet-Anbindung durch diesen Router hindurch funktioniert? Antwort: “Nein”. Typischerweise sollte also hier eine EXPLIZITE IP-ADRESSEkonfiguriert werden, die irgendwo tatsächlich im Internet liegt.

 

  • Problem 2 (Szenario PPPoE oder DHCP-Einwahl) => Das Default Gateway des Interfaces wird dem Interface vom Provider erst bei der Einwahl zugewiesen. In vielen Fällen (providerabhängig!)antwortet aber genau diese als Default Gateway zugewiesene IP-Adresse nicht auf ping. Was ist also das Resultat im Default-Zustand? Das Interface arbeitet zunächst (3+1) x 15 => 60 Sekunden ordnungsgemäß, wird dann jedoch von der WatchGuard als “INACTIVE” eingestuft und aus dem Multi-WAN-Verfahren herausgenommen… Insbesondere in diesem Fall sollte also UNBEDINGT eine tatsächliche IP-Adresse im Internet als ping-Ziel definiert werden…

Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verfügbarkeit von externen Systemen abhängig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverfügbar ausgelegt sind: 8.8.8.8, 4.2.2.3, 141.1.1.1 oder die typischen DNS-Server der Telekom 194.25.0.60, 194.25.0.68, 194.25.0.52, 194.25.2.129 etc. Providerunabhängig lautet meine Empfehlung generell:Verwenden Sie hier nach Rücksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverfügbar ausgelegt ist – und die sich nicht in absehbarer Zeit ändern wird!

(Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgeführt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gemäß o.g. ausmalen kann… War zum Glück an einem Wochenende…)

Nachdem nun die Voraussetzungen für das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tatsächlichen PBR (Policy Based Routing) Firewall-Regeln herangehen.

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B.http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interfaceauszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehendeHTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.