{"id":637,"date":"2016-06-16T17:49:15","date_gmt":"2016-06-16T15:49:15","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=637"},"modified":"2016-06-16T18:31:03","modified_gmt":"2016-06-16T16:31:03","slug":"funktionsweise-des-watchguard-firebox-regelwerks","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2016\/06\/funktionsweise-des-watchguard-firebox-regelwerks\/","title":{"rendered":"Funktionsweise des WatchGuard Firebox Regelwerks"},"content":{"rendered":"<p>Die WatchGuard Firewall pr\u00fcft 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\u00e4chst 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 &#8220;von oben nach unten&#8221; (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).<br \/>\nNacheinander wird jede einzelne Regel gepr\u00fcft, ob sie die o.g. Kriterien erf\u00fcllt &#8211; so lange bis der erste &#8220;Treffer&#8221; gefunden wird. Nur diese Regel wird auch ausgef\u00fchrt. Gibt es &#8220;weiter hinten&#8221; im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht\/ausgef\u00fchrt. 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\u00e4tzliche Kontrolle des Inhalts vornehmen).<\/p>\n<p>Ganz am Ende des Regelwerks steht eine <strong>unsichtbare Deny Regel<\/strong>. Jeder Datenverkehr, der nicht ausdr\u00fccklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von au\u00dfen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein <strong>Unhandled Internal Packet<\/strong> oder ein<strong>Unhandled External Packet<\/strong>.<\/p>\n<p><strong>Warum werden die Unhandled Packets angezeigt?<\/strong><\/p>\n<p>Weil im Policy Manager bei <em>Setup &gt; Default Threat Protection &gt; Deafult Packet Handling &gt; Logging<\/em> das H\u00e4kchen &#8220;Send Log message&#8221; bei den Kategorien &#8220;Unhandled Internal Packet&#8221; und &#8220;Unhandled External Packet&#8221; gesetzt ist. Das Logging k\u00f6nnte zwar durch Entfernen des H\u00e4kchens ausgeschaltet werden &#8211; 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\u00fcr neue Regeln zu erkennen und wie diese auszusehen haben.<\/p>\n<p><strong>Das Default Regelwerk und die globale Outgoing-Regel<\/strong><\/p>\n<p>Der <strong>Quick Setup Wizard<\/strong> erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip s\u00e4mtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zul\u00e4sst &#8211; und s\u00e4mtlichen eingehenden Verkehr (incoming) verbietet.<br \/>\nGewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zul\u00e4ssig ist und diesen auf Maschinen- und\/oder User-Ebene auf das absolute Minimum beschr\u00e4nken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie m\u00f6glich einschr\u00e4nkt. Ein gutes Firewall-Regelwerk w\u00e4chst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das sch\u00f6ne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultm\u00e4\u00dfig vorhandene<strong>Outgoing-Regel auf disabled gesetzt oder ganz gel\u00f6scht wird<\/strong>. Denn: das Regelwerk wird &#8220;von oben nach unten&#8221; abgearbeitet, der erste Treffer z\u00e4hlt. Solange &#8220;unten&#8221; die globale Outgoing-Regel steht, n\u00fctzen die Einschr\u00e4nkungen weiter &#8220;oben&#8221; nichts. Der Verkehr w\u00fcrde trotzdem \u00fcber die Outgoing-Regel rausgehen, also weg damit!<\/p>\n<p><strong>Anzeige von bestimmten Unhandled Packets unterdr\u00fccken<\/strong><\/p>\n<p>Bisweilen \u00e4rgert man sich doch \u00fcber die Anzeige von Unhandled Packets. Eventuell kann man die Ursache daf\u00fcr einfach nicht abstellen usw. Bei der L\u00f6sung hilft nun das bisher Gesagte: das unzul\u00e4ssige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel f\u00fcr diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks h\u00e4ngen.<br \/>\nDer 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 (&#8220;Denied&#8221;) &#8211; und das Logging ausschaltet. Der l\u00e4stige Verkehr taucht k\u00fcnftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:<\/p>\n<p><a href=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/SYSHFDHRHuI\/AAAAAAAAAEs\/PeGgL03_WpM\/s1600-h\/denied-no-logging-3.JPG\"><img decoding=\"async\" id=\"BLOGGER_PHOTO_ID_5297507582499430114\" src=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/SYSHFDHRHuI\/AAAAAAAAAEs\/PeGgL03_WpM\/s320\/denied-no-logging-3.JPG\" alt=\"\" border=\"0\" \/><\/a><\/p>\n<p><strong>Konfigurationsbeispiel: HostWatch Namensaufl\u00f6sung (Port 137\/udp) unterdr\u00fccken<\/strong><\/p>\n<p><a href=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/SYSFJ2oigGI\/AAAAAAAAAEc\/MkxLUoZKAtA\/s1600-h\/denied-no-logging-1.JPG\"><img decoding=\"async\" id=\"BLOGGER_PHOTO_ID_5297505466025410658\" src=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/SYSFJ2oigGI\/AAAAAAAAAEc\/MkxLUoZKAtA\/s320\/denied-no-logging-1.JPG\" alt=\"\" border=\"0\" \/><\/a><\/p>\n<p>Properties &gt; Logging<\/p>\n<p><a href=\"http:\/\/1.bp.blogspot.com\/_haYpXd-8uFA\/SYSFY6fL5sI\/AAAAAAAAAEk\/CFF9ZRx6Lvs\/s1600-h\/denied-no-logging-2.JPG\"><img decoding=\"async\" id=\"BLOGGER_PHOTO_ID_5297505724757960386\" src=\"http:\/\/1.bp.blogspot.com\/_haYpXd-8uFA\/SYSFY6fL5sI\/AAAAAAAAAEk\/CFF9ZRx6Lvs\/s320\/denied-no-logging-2.JPG\" alt=\"\" border=\"0\" \/><\/a><\/p>\n<p>Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel f\u00fcr den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen fr\u00fcher gepr\u00fcft. Das kennen wir: ein explizites Verbot ist m\u00e4chtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsm\u00f6glichkeit 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\u00f6hlich hin- und hergepingt werden &#8211; auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn&#8217;s st\u00f6rt, kann f\u00fcr die Denied-Regel nat\u00fcrlich auch das Logging ausgeschaltet werden&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Die WatchGuard Firewall pr\u00fcft 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\u00e4chst 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 &#8220;von oben nach unten&#8221; (wenn man sich in der Standard-Listenansicht des Policy Managers befindet). &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2016\/06\/funktionsweise-des-watchguard-firebox-regelwerks\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">Funktionsweise des WatchGuard Firebox Regelwerks<\/span> <span class=\"meta-nav\">&raquo;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[48,49],"class_list":["post-637","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-policy","tag-regelwerk"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/637"}],"collection":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/comments?post=637"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/637\/revisions"}],"predecessor-version":[{"id":639,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/637\/revisions\/639"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=637"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=637"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}