Category Archives: Technischer Blog

WebBlocker active / inactive

Comment

Bisweilen findet man im Traffic Monitor Einträge wie:

proxy[1756] webblocker server=IP:5003/udp is now active
proxy[1756] webblocker server=IP:5003/udp is now inactive
proxy[1756] webblocker server=IP:5003/udp is now active
proxy[1756] webblocker server=IP:5003/udp is now inactive

Diese Meldungen haben nur informellen Charakter, man kann sie getrost ignorieren. Das Verhalten ist durchaus normal und tritt dadurch auf, dass der WebBlocker-Dienst eine gewisse Zeit lang nichts zu tun hat, wodurch die udp-Verbindung zwischen der Firebox und dem WebBlocker Server in einen idle-Timeout läuft, getrennt wird und dadurch die Meldung “inactive” auslöst. Wenn der WebBlocker dann das nächste Mal wieder angesprochen wird, springt der Status wieder auf “active”. In den allermeisten Fällen liegt somit kein akutes Problem vor.

Version 10.2.8 im Download-Bereich

2 Comments

Folgende Änderungen im Installationsverhalten ist mir aufgefallen: Beim Aufruf des Installers fireware10_2_8.exe kommt nicht mehr die verwirrende Meldung “Do you want to completely remove the selected application and all of its features?”, sondern zu der schon existierenden Version 10.2.x wird zusätzlich die Fireware 10.2.8 installiert. Zur Vermeidung von Fehlern empfehle ich nun, als ersten Schritt über Systemsteuerung > Software die bisherige Version Fireware 10.2.x zu deinstallieren – und anschließend den Installer fireware10_2_8.exe aufzurufen.

Weiterhin stehen im Download-Bereich neue Versionen für den IPSec Mobile User VPN-Client, den SSL-VPN-Client sowie für den Single Sign On (SSO) Client und Agent (Gateway).

Version 10.2.8 steht unmittelbar bevor

Comment

Die Release Notes liegen schon vor. Die Build-Nummer der Fireware 10.2.8 wird B215550 lauten. Hier die dieses Mal ganz besonders lange Liste der Resolved Issues. Ganz dringend erwartet wird sicher der allererste Bugfix auf der Liste (Upper Port Fix). Mit vielen anderen Punkten hatte ich aber in der Praxis gar keine Berührung. Fireware und WSM 10.2.8 sollen noch im Laufe dieser Woche, spätestens aber bis zum 31.03.2009 im Download-Bereich der WatchGuard Website bereitgestellt werden. Für die Installation ist eine aktive Live Security Lizenz erforderlich:

General

  • This release resolves several stability issues on Firebox devices that have the upper 4 ports in use. [27896] [29899] [30057] [30093]

  • You can now connect to a Firebox with WSM or Firebox System Manager more reliably after running a high load on the Firebox for several days. [35309]

  • The time it takes to save a configuration is reduced as much as 60% when there are many policies. [27791]

  • The Firebox can continue to operate even when IPS is using 100% of the CPU. [31361]

  • Support files are now correctly rotated so they do not take up so much storage space. [33551]

Networking and VPN

  • This release fixes an instability issue with PPPoE. [29212]

  • The Firebox no longer stops getting OSPF routing table information from neighboring networks. [27202]

  • The IKED process no longer becomes non-responsive when two users log in with the same name and same IP address. [33067] [33361]

  • The MIA process no longer crashes during a configuration save when multiple mobile VPN users are logged in. [33617]

  • Users now can use Mobile VPN (SSL, PPTP, and IPSec) with a dynamically addressed external interface without using DynDNS. [32707] [32715] [32716]

  • You can now use a space in user names configured on the Firebox. [33687]

  • Server Load Balancing now detects the revival of a dead server within 30 seconds instead of 10 minutes.

WatchGuard System Manager (WSM)

  • The traffic load gauge on Traffic Monitor no longer incorrectly shows 100% even when the load is low on Firebox X Peak e-Series devices. [27950]

  • The Firebox System Manager Traffic Monitor function “highlight search results” is now case insensitive. [33318]

  • The sender address is now shown in Log Server alarm/notification emails. [31489]

  • The Report Server can now generate POP3 reports. [32974]

  • Devices are now correctly marked as connected when you use multiple Log Servers. [31524]

  • The spamBlocker report no longer incorrectly reports 100% bulk mail. [28562]

Single Sign-On

  • The SSO login information on the Authentication List now refreshes immediately. [31856]

  • The SSO agent no longer crashes with Windows Event message: EventType clr20r3. [32775]

  • The SSO client now returns the correct domain name.

  • The SSO client and agent now handle both AD domain name information and NetBIOS domain name information correctly.

  • The SSO client and agent now respond correctly to unexpected disconnections that occur within 10 seconds.

High Availability

  • HA monitoring on external fiber interface now works correctly. [32967]

  • When you enable HA, it no longer causes a branch office VPN rekey to occur approximately every two minutes. [33402]

  • HA failover now occurs immediately when a critical process fails. [33823]

Mobile VPN with SSL

  • The SSLVPN daemon no longer fails when you enter an empty password or a very long password. [31894] [35183]

  • The Mobile VPN with SSL Mac OS X client now shows the Bound IP Address and Gateway Connected IP Address correctly. [34561]

  • The Mobile VPN with SSL Mac OS X client now removes the search domain and DNS information when it is disconnected or you exit. [34564]

  • The Mobile VPN with SSL Mac OS X client now shows both WINS addresses. [34560] [23635]

  • The Mobile VPN with SSL Mac OS X client now sets the default log level to low. [34563]

  • Routes of available networks are now correctly added when you install the Mobile VPN with SSL client software on a computer running Windows Vista. [34558]

X Edge running from a backup copy of firmware

4 Comments

Heute kam eine WatchGuard Firebox X Edge von einem Kunden zurück mit folgender Fehlerbeschreibung: Zurücksetzen auf Factory Default führt zu kurzzeitiger Erreichbarkeit (ping) unter 192.168.111.1, jedoch kein Zugriff über https. Nach einem regulären Neustart überhaupt keine Reaktion.

Nach einem erneuten Rücksetzen auf Factory Default reagiert die Box auf http (nicht https!). Es erscheint folgende Fehlermeldung: “Your WatchGuard Firebox Edge is running from a backup copy of firmware. Your unit can be restored by sending the required files using FTP. Status of firmware: SYSA partition is valid. Serial Number is [xxx]. Reset button IS pressed. SYSB version 8.0.”

Im vorliegenden Zustand läuft die X Edge in einem Mini-Betriebssystem, das in der Partition SYSB fest hinterlegt ist. Das eigentliche Betriebssystem, das in SYSA liegen sollte, ist entweder beschädigt oder gar nicht vorhanden. Eine Reparatur kann auf zwei Wegen erfolgen:

1. Mit Hilfe der aktuellen EXE-Datei edge_10_2_7.exe aus dem Software Download Bereich: X Edge wieder auf Factory Default setzen (beim Einschalten den Reset-Knopf mindestens 45 Sekunden lang gedrückt halten) und die o.g. EXE-Datei von einem Windows 2000/XP/2003-PC (nicht Vista!) aus starten. Der PC muss für TCP/IP so konfiguriert sein, dass er die Default-IP der X Edge (192.168.111.1) erreicht. Sofern der Wizard erfolgreich durchläuft, kann die X Edge anschließend wieder wie üblich neu eingerichtet werden.

2. Mit Hilfe der ZIP-Datei: ZIP-Datei auf einem PC auspacken, so dass auf die darin enthaltene Datei yakfw.sysa-dl zugegriffen werden kann. Firebox X Edge auf Factory Default setzen. Sicherstellen, dass der PC die IP 192.168.111.1 erreichen kann. MS-DOS-Eingabeaufforderung (cmd) öffnen und in das Unterverzeichnis wechseln, in dem die Datei yakfw.sysa-dl liegt:
ftp 192.168.111.1 (User=admin, Passwort=admin)
bin (Umschalten in den Binary Mode)
put yakfw.sysa-dl
X Edge booten lassen. Anschließend sollte die Box wieder wie üblich neu eingerichtet werden können.

Keine Umlaute und Sonderzeichen in der Konfiguration!

1 Comment

Nach fast 3 Wochen Abstinenz nun mal wieder ein kleines Lebenszeichen. Aus gegebenem Anlass nur ein kurzer Hinweis auf ein eigentlich bekanntes Known Issue:

Verwenden Sie im Zusammenhang mit WatchGuard-Konfigurationen, Kennwörtern, Pre-Shared Keys usw. ausschließlich druckbare Zeichen des US-ASCII Zeichensatzes (ASCII-7) – vgl. http://de.wikipedia.org/wiki/ASCII.

Die Verwendung anderer Zeichen, z.B. deutsche Umlaute (ä,ö,ü,ß) und höherbittige Sonderzeichen, kann zu nicht vorhersagbarem Verhalten der WatchGuard Firebox führen! Ich selbst gehe sogar noch einen Schritt weiter: insbesondere bei den Firewall-Kennwörten und Pre-Shared Keys beschränke ich mich auf die Buchstaben A-Z, a-z und die Ziffern 0-9 – und verzichte entgegen dem Komplexitätsgedanken instinktiv auf Sonderzeichen.
Ich habe neulich die Migration eines Clusters aus zwei Firebox X5500e von der Fireware 9.1 auf die aktuelle Fireware 10.2.7 durchgeführt. Die ursprüngliche Einrichtung wurde von einem anderen Dienstleister vorgenommen, der in den Firewall-Kennwörtern (Status Passphrase und Configuration Passphrase) jeweils ein $ (Dollarzeichen) verwendet hatte, was auch bei der Fireware 9.1 offenbar funktioniert hat. Nach dem Software-Update auf 10.2.7 liefen die Boxen jedoch instabil und konnten vom WSM auch nach kurzer Laufzeit nicht mehr angesprochen werden. Das Rücksetzen auf Factory Default habe ich dann nicht mit dem normalen “Quick Setup Wizard” (Windows-Applikation), sondern über den “Web Quick Setup Wizard” im Safe Mode vorgenommen. Der Web Quick Setup Wizard hat dann übrigens auch die Verwendung des Dollarzeichens in den Passphrases abgelehnt, der normale Quick Setup Wizard hingegen akzeptiert Dollars 🙂 Ohne Sonderzeichen in den Kennwörten liefen die Boxen dann auch mit unveränderter Konfiguration wieder klaglos…

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

3 Comments

Als Fortsetzung zu Teil 1 von gestern bietet sich die folgende Überlegung an:

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

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 mißbrauchte 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.

(Fortsetzung folgt…)

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…

Fireware Installer zweimal starten

Comment

Wenn eine neue Fireware-Version (z.B. 10.2.7) auf eine Windows Management Station installiert werden soll, auf der sich bereits eine etwas ältere Version (z.B. 10.2.6) befindet, erscheint nach dem Aufruf des (neuen) Fireware-Installers die Meldung “Do you want to completely remove the selected application and all of its features?”:

Diese Meldung verwundert zunächst: warum soll etwas deinstalliert werden – es soll doch etwas installiert werden… Antworten Sie mit JA! Nun wird zunächst die ältere Version deinstalliert! Rufen Sie anschließend den Fireware-Installer einfach ein zweites Mal auf. Erst dann wird die neue Fireware-Version tatsächlich installiert…