Tag Archives: Konfiguration

E-Mail-Sicherheit mit dem SMTP-proxy (1)

Comment

Der Application Proxy für SMTP steht in allen WatchGuard Firebox Software-Versionen zur Verfügung – in der normalen Fireware, in der Fireware Pro und auch in den älteren 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 möglich sind:

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

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 werden!

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.

(Fortsetzung folgt…)

IKE Keep Alive und Dead Peer Detection (DPD)

1 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.

Die WatchGuard Fireboxen kennen mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen: IKE Keep Alive, Dead Peer Detection – und bei der X Edge Serie zusätzlich noch VPN Keep Alive.

IKE Keep Alive sollte nur eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen!
Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Die aktuellen Default Einstellungen sollten auch verwendet werden: NAT-Traversal (aktiv), 20 Sekunden. Bei Nutzung von IKE Keep Alive: 30 Sekunden, max. 5 Failures. Bei Nutzung von DPD: 20 Sekunden, max. 5 Versuche. 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…

Auf der 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):

Es wird empfohlen, sich jedoch nur auf EIN Verfahren zu beschränken!

Funktionsweise des WatchGuard Firebox Regelwerks

4 Comments

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 ein Unhandled 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 vorhandene Outgoing-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…

X Edge: Zugriff auf Konfigurationsdatei per FTP

Comment

Im Normalzustand akzeptiert eine Firebox X Edge FTP-Verbindungen auf ihrem Trusted Interface. Öffnen Sie eine MSDOS-Eingabeaufforderung: ftp IP-der-Firebox. Nach Eingabe von Username/Password (die gleichen Credentials wie bei der Anmeldung über das Webinterface) wird durch Eingabe von bin in den Binary Mode gewechselt. Anschließend kann mit dem Befehl get wg.cfg die Konfigurationsdatei der X Edge geholt werden. Die Datei wg.cfg steht dann an genau der Stelle des Filesystems unseres PC, von dem aus der FTP-Befehl gestartet wurde (im Regelfall C:Dokumente und EinstellungenUSERPROFIL). Hier kann die Datei dann mit einem Texteditor (z.B. Wordpad) bearbeitet werden. Dass hierbei natürlich äußerste Vorsicht geboten ist, versteht sich von selbst! Die geänderte Konfigurationsdatei kann dann in der FTP-Verbindung mit dem Befehl put wg.cfg wieder auf die X Edge hochgeladen werden. Die meisten Änderungen werden zwar sofort on-the-fly übernommen, die X Edge sollte jedoch abschließend einmal neu gebootet werden.

ACHTUNG: Die Datensicherheit ist bei dieser Vorgehensweise nur gewährleistet, wenn Sie sich entweder direkt vom Trusted Network aus mit der X Edge verbinden – oder durch einen VPN-Tunnel (egal ob Branch Office VPN oder Mobile User VPN): FTP überträgt Benutzernamen und Kennwort bei der Anmeldung im Klartext!!! Auch die Übertragung der Konfigurationsdatei erfolgt unverschlüsselt! In der Konfigurationsdatei stehen z.B. solche sensiblen Daten wie die Preshared Keys von VPN-Tunneln im KLARTEXT!!!

Von außen über das Internet sollte also nur im Notfall von dieser Methode Gebrauch gemacht werden (temporär Firewall > Incoming > FTP > Allow > [NAT:Trusted-IP-der-Firebox] einschalten). Anschließend sollten auf jeden Fall Firewall-Kennwort und Preshared Keys in einer gesicherten Verbindung geändert werden! Der FTP-Zugriff auf die X Edge kann auch deaktiviert werden: Firewall > Firewall Options > Do not allow FTP access to the Edge from the Trusted Network (bzw. Optional Network). Praktische Anwendungsfälle sind Backup/Restore/Archivierung von Konfigurationen – und wenn Sie mehrere Änderungen am Regelwerk gleichzeitig vornehmen müssen, z.B. per Fernwartung/HTTPS die IP-Adresse des Trusted Interface ändern und gleichzeitig auch den Incoming NAT-Eintrag anpassen, über den eben genau die Fernwartungssitzung läuft (der berühmte Ast, auf dem man gerade sitzt… 🙂

Wenn es nur um das Auslesen der Konfigurationsdatei geht, ist es besser, sie sich SSL-verschlüsselt über das Webinterface anzeigen zu lassen (Administration > View Configuration) und mit Cut&Paste in eine Textdatei weg zu speichern…

HA Cluster: “Peer Status is in-transition”

Comment

Beim Speichern einer neuen Konfiguration auf einen HA Cluster kommt es bisweilen zu dem Zustand Peer Status is in-transition anstelle des normalen “Peer Status is standby”. Zu diesem Verhalten kann es kommen, wenn während des Speicherns gerade mobile User über PPTP-VPN eingewählt sind.

[30.01.2009]: Laut Release Notes soll dies nun mit der Fireware 10.2.7 behoben sein.

BOVPN Notification einschalten

1 Comment

Wenn die Firebox 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 Logging lediglich das Triggersignal dazu!

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

X Edge: versteckte Debug-Funktionen

1 Comment

Die Firebox X Edge hat eine nicht dokumentierte Seite, die zum Testen und für Debug-Zwecke sehr hilfreich ist:
https://IP-DER-FIREBOX/shakne.htm.
Im Abschnitt Property Management können mit den Funktionen “Get Property”, “Put Property” und “Delete Property” einzelne Parameter in der Konfigurationsdatei hinzugefügt, verändert und gelöscht werden, die über die GUI sonst nicht erreichbar wären. Ähnlich wie beim manuellen Eingriff in die Registry eines Windows-Rechners ist hier natürlich ein konkreter Anlass und äußerste Sorgfalt angesagt!
Die Funktion Ping setzt einen Ping direkt von der Firebox an die eingegebene Zieladresse ab. Das ist äußerst hilfreich, z.B. wenn man sich gerade einmal nicht auf anderes Testsystem an dem Standort aufschalten kann…

Weiter unten finden sich noch verschiedene Debug-Hilfen – unter anderem kann hier auch das Logging Level für die Application Proxies hochgesetzt werden (wirklich nur für Debug-Zwecke, denn natürlich erzeugt das erweiterte Logging Last auf der Firewall…)

XML-Konfigurationsdatei auf anderes Modell portieren

Comment

Nach etwas Urlaub nun wieder etwas Arbeit… 🙂 Eine urspünglich für ein bestimmtes Modell erstellte XML-Konfigurationsdatei kann auch für alle anderen X Core und X Peak Modelle mit Fireware angepasst und verwendet werden. Hierzu wird die Datei mit dem Policy Manager geöffnet und bei Setup > System > Firebox Model wird das neue Modell ausgewählt. Ändert sich dadurch die Anzahl der an der Hardware vorhandenen Netzwerk-Interfaces, erscheint eine Warnmeldung:

Nach dem Klick auf Ja kommt folgende Bestätigung und die Konfiguration kann dann entsprechend weiter angepasst werden:

Ein kleines Problem tritt auf, wenn die Modellnummer des neuen Geräts NIEDRIGER ist als die in der Konfigurationsdatei (X550e ist zum Beispiel niedriger als X700, X5000 ist niedriger als X5500e)! Dann verweigert der Policy Manager nämlich zunächst den Modellwechsel (“The model number must not be lower than the base model:Xxxx”):

Der Trick besteht nun darin, vorher die XML-Konfigurationsdatei mit einem Texteditor zu öffnen (der Default Pfad zu den Konfig-Dateien ist Eigene DateienMy WatchGuardconfigs). Relativ weit oben in der XML-Datei (etwa um die achte Zeile herum) befindet sich der Tag

< base-model > X5500e < / base-model > .

Diese Zeile muss komplett GELÖSCHT werden. Anschließend die XML-Datei speichern und mit dem Policy Manager öffnen. Dann sollte die Modelländerung problemlos vonstatten gehen… Eine Modelländerung ist ja auch immer mit einem Wechsel der Hardware/Seriennummer verbunden. Natürlich muss daher auch immer der Feature Key ausgetauscht werden: Setup > Feature Keys. Alten Feature Key removen, neuen Feature Key importieren.