Andreb (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Andreb (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 319: | Zeile 319: | ||
{{var | Allowlisting Beispiele | {{var | Allowlisting Beispiele | ||
| Allowlisting Beispiele | | Allowlisting Beispiele | ||
| | | Allowlisting example }} | ||
{{var | | {{var | Allowlisting Beispiele--desc | ||
| In diesem Beispiel wurde die URL '''www.google.de''' und die Kategorie '''Ausbildung''' über die Funktion {{Button|+ Regel hinzufügen}} zum | | In diesem Beispiel wurde die URL '''www.google.de''' und die Kategorie '''Ausbildung''' über die Funktion {{Button|+ Regel hinzufügen}} zum Allowlisting hinzugefügt.<br> {{Hinweis-box||g}} Da der Webfilter die Regeln von oben nach unten bearbeitet, musste in diesem Beispiel die Kategorie ''Ausbildung'' manuell an die erste Stelle geschoben werden. | ||
| In this example, the URL '''www.google.de''' and the category '''Education''' were added to the | | In this example, the URL '''www.google.de''' and the category '''Education''' were added to the allowlisting via the function {{Button|+ Add rule}}.<br> {{Hinweis-box||g}} Since the web filter processes the rules from top to bottom, in this example the category ''Education'' had to be manually pushed to the first position. }} | ||
{{var | | {{var | Allowlisting Beispiele--Bild | ||
| UTM v12.6 Webfilter | | UTM v12.6 Webfilter Allowlist Beispiele.png | ||
| UTM v12.6 Webfilter | | UTM v12.6 Webfilter Allowlist Beispiele-en.png }} | ||
{{var | Sonstiges | {{var | Sonstiges | ||
| Sonstiges | | Sonstiges | ||
| Zeile 339: | Zeile 339: | ||
| Architecture of the Webfilter }} | | Architecture of the Webfilter }} | ||
{{var | Architektur des Webfilter--desc | {{var | Architektur des Webfilter--desc | ||
| Der Webfilter arbeitet mit URL- und Kategorien-Regelsätzen, die in Profilen Netzwerkgruppen oder Benutzergruppen zugeordnet werden müssen.<br><br> Der Ablauf ist wie folgt:<br> Ein Benutzer ruft über einen Browser oder eine andere Anwendung eine Webseite auf. Die Datenpakete, inklusive dem Uniform Resource Locator (URL) der Webseite, werden über den HTTP Proxy geleitet. Entweder dadurch, dass der HTTP Proxy als transparenter Proxy eingerichtet ist, oder durch die Proxy-Konfiguration des Browsers am Client.<br> Je nachdem ob zuerst ein Profil für eine Benutzergruppe oder eine Netzwerkgruppe angelegt wurde, wird überprüft, ob der Benutzername oder die IP-Adresse mit einem Profil übereinstimmt.<br> Stimmt weder der Benutzername noch die Quell IP-Adresse mit einem Gruppen-Profil überein, greift die Standard Aktion, die unter ''Webfilter'' im Bereich ''Allgemein'' unter ''Kein passendes Profil gefunden:'' definiert wurde. Es werden diese Anforderungen, je nach Einstellung im Webfilter, entweder zugelassen oder geblockt.<br> Nachdem ein Profil erkannt wurde, wird der damit verknüpfte Regelsatz überprüft.<br> Zunächst wird die zeitliche Gültigkeit des Regelsatzes überprüft. Stimmt diese nicht überein, prüft der Webfilter ob ein weiterer Regelsatz für dieses Profil hinterlegt ist. Ist dieses nicht der Fall, greift die Webfilter Standard Aktion.<br> Ist der Regelsatz nicht zeitlich geregelt oder stimmt der Regelsatz zeitlich überein, wird als nächstes überprüft, ob dieser Regelsatz den Zugang grundsätzlich blockieren soll. Das ist der Fall, wenn im Fenster ''Regelsatz bearbeiten'' die Markierung bei ''Zugang blockieren:'' gesetzt wurde.<br> Wird mit dem Regelsatz nicht alles blockiert, überprüft der Webfilter die hier hinterlegten URLs und vergleicht diese mit der Anforderung des Clients. Ist die URL oder Teile der URL im Regelsatz eingetragen, wird geprüft, ob diese auf der Allowlist oder auf der Blocklist stehen und dadurch zugelassen oder geblockt werden.<br> Ist die angeforderte URL nicht eingetragen, wird überprüft ob diese zu einer Kategorie passen.<br> Dazu wird zunächst geprüft, ob diese URL schon einmal auf die Zuordnung zu einer Kategorie geprüft wurde und ob sich diese Anfrage noch im Cache befindet.<br> Ist das nicht der Fall, wird über die UTM eine Anfrage an die Securepoint Contentfilter-Server gestellt, die ähnlich einer DNS Anfrage funktioniert: Die URL wird zunächst zum Server übertragen. Die Anfrage wird mit einer IP-Adresse beantwortet, die den Webfilter darüber informiert, in welcher Kategorie sich diese URL befindet.<br> Nun wird überprüft, ob die Kategorie aufgelistet und auf einer | | Der Webfilter arbeitet mit URL- und Kategorien-Regelsätzen, die in Profilen Netzwerkgruppen oder Benutzergruppen zugeordnet werden müssen.<br><br> Der Ablauf ist wie folgt:<br> Ein Benutzer ruft über einen Browser oder eine andere Anwendung eine Webseite auf. Die Datenpakete, inklusive dem Uniform Resource Locator (URL) der Webseite, werden über den HTTP Proxy geleitet. Entweder dadurch, dass der HTTP Proxy als transparenter Proxy eingerichtet ist, oder durch die Proxy-Konfiguration des Browsers am Client.<br> Je nachdem ob zuerst ein Profil für eine Benutzergruppe oder eine Netzwerkgruppe angelegt wurde, wird überprüft, ob der Benutzername oder die IP-Adresse mit einem Profil übereinstimmt.<br> Stimmt weder der Benutzername noch die Quell IP-Adresse mit einem Gruppen-Profil überein, greift die Standard Aktion, die unter ''Webfilter'' im Bereich ''Allgemein'' unter ''Kein passendes Profil gefunden:'' definiert wurde. Es werden diese Anforderungen, je nach Einstellung im Webfilter, entweder zugelassen oder geblockt.<br> Nachdem ein Profil erkannt wurde, wird der damit verknüpfte Regelsatz überprüft.<br> Zunächst wird die zeitliche Gültigkeit des Regelsatzes überprüft. Stimmt diese nicht überein, prüft der Webfilter ob ein weiterer Regelsatz für dieses Profil hinterlegt ist. Ist dieses nicht der Fall, greift die Webfilter Standard Aktion.<br> Ist der Regelsatz nicht zeitlich geregelt oder stimmt der Regelsatz zeitlich überein, wird als nächstes überprüft, ob dieser Regelsatz den Zugang grundsätzlich blockieren soll. Das ist der Fall, wenn im Fenster ''Regelsatz bearbeiten'' die Markierung bei ''Zugang blockieren:'' gesetzt wurde.<br> Wird mit dem Regelsatz nicht alles blockiert, überprüft der Webfilter die hier hinterlegten URLs und vergleicht diese mit der Anforderung des Clients. Ist die URL oder Teile der URL im Regelsatz eingetragen, wird geprüft, ob diese auf der Allowlist oder auf der Blocklist stehen und dadurch zugelassen oder geblockt werden.<br> Ist die angeforderte URL nicht eingetragen, wird überprüft ob diese zu einer Kategorie passen.<br> Dazu wird zunächst geprüft, ob diese URL schon einmal auf die Zuordnung zu einer Kategorie geprüft wurde und ob sich diese Anfrage noch im Cache befindet.<br> Ist das nicht der Fall, wird über die UTM eine Anfrage an die Securepoint Contentfilter-Server gestellt, die ähnlich einer DNS Anfrage funktioniert: Die URL wird zunächst zum Server übertragen. Die Anfrage wird mit einer IP-Adresse beantwortet, die den Webfilter darüber informiert, in welcher Kategorie sich diese URL befindet.<br> Nun wird überprüft, ob die Kategorie aufgelistet und auf einer Allow- oder Blocklist steht. Daraufhin wird die Anfrage an diese URL zugelassen oder geblockt.<br> Es ist möglich, dass eine URL in mehreren Kategorien enthalten ist. Die Anfrage an die Contentfilter-Server wird wiederholt, sowie mit den weiteren Einträgen in der Liste abgeglichen.<br> Sind weder die URL noch eine passende Kategorie in den Regeln hinterlegt, trifft die Einstellung unter "Regelsatz bearbeiten" "Keine passende Regel gefunden" zu. Hier kann pro Regelsatz ein abweichendes Verhalten zu den default Regeln eingestellt werden. Sollten die Kategorien nicht auflösbar sein so gilt hier ebenfalls das unter "Regelsatz bearbeiten" "Kategorie nicht auflösbar" eingestellte Verhalten. | ||
| The Webfilter works with URL and category rule sets that must be assigned to network groups or user groups in profiles.<br> | | The Webfilter works with URL and category rule sets that must be assigned to network groups or user groups in profiles.<br> | ||
The process is as follows:<br> A user accesses a web page via a browser or another application. The data packets, including the Uniform Resource Locator (URL) of the website, are routed through the HTTP proxy. Either by the HTTP proxy being set up as a transparent proxy or by the proxy configuration of the browser on the client.<br> Depending on whether a profile was first created for a user group or a network group, it is checked whether the username or the IP address matches a profile.<br> If neither the username nor the source IP address matches a group profile, the default action defined under ''Webfilter'' in the ''General'' section under ''No matching profile found:'' takes effect. These requests are either allowed or blocked, depending on the setting in the Webfilter.<br> After a profile is recognised, the rule set associated with it is checked.<br> First, the temporal validity of the rule set is reviewed. If this does not match, the Webfilter checks whether another rule set is stored for this profile. If this is not the case, the standard action of the Webfilter takes effect.<br> If the rule set is not timed or if the rule set matches in time, the next step is to check whether this rule set should block access in principle. This is the case if in the window ''Edit Rule set'' the check box ''Block Access:'' has been set.<br> If not everything is blocked with the rule set, the Webfilter checks the URLs stored here and compares them with the client's request. If the URL or parts of the URL are listed in the rule set, it is checked whether they are on the allowlist or on the blocklist and thus allowed or blocked.<br> If the requested URL is not listed, the system checks whether it fits into a category.<br> To do this, it first checks whether this URL has already been reviewed for assignment to a category and whether this request is still in the cache.<br> If this is not the case, a request is made to the Securepoint content filter servers via the UTM, which works similar to a DNS request: The URL is first transmitted to the server. The request is answered with an IP address that informs the Webfilter in which category this URL is listed.<br> Now it is checked whether the category is listed and on a allow or blocklist. The request to this URL is then allowed or blocked.<br> It is possible that a URL is listed in several categories. The request to the content filter servers is repeated and compared with the other entries in the list.<br> If neither the URL nor a suitable category are stored in the rules, the setting under "Edit rule set" "No suitable rule found" applies. Here, a different behaviour to the default rules can be set for each rule set. If the categories are not resolvable, the behaviour set under "Edit rule set" "Category irresolvable" also applies here. }} | The process is as follows:<br> A user accesses a web page via a browser or another application. The data packets, including the Uniform Resource Locator (URL) of the website, are routed through the HTTP proxy. Either by the HTTP proxy being set up as a transparent proxy or by the proxy configuration of the browser on the client.<br> Depending on whether a profile was first created for a user group or a network group, it is checked whether the username or the IP address matches a profile.<br> If neither the username nor the source IP address matches a group profile, the default action defined under ''Webfilter'' in the ''General'' section under ''No matching profile found:'' takes effect. These requests are either allowed or blocked, depending on the setting in the Webfilter.<br> After a profile is recognised, the rule set associated with it is checked.<br> First, the temporal validity of the rule set is reviewed. If this does not match, the Webfilter checks whether another rule set is stored for this profile. If this is not the case, the standard action of the Webfilter takes effect.<br> If the rule set is not timed or if the rule set matches in time, the next step is to check whether this rule set should block access in principle. This is the case if in the window ''Edit Rule set'' the check box ''Block Access:'' has been set.<br> If not everything is blocked with the rule set, the Webfilter checks the URLs stored here and compares them with the client's request. If the URL or parts of the URL are listed in the rule set, it is checked whether they are on the allowlist or on the blocklist and thus allowed or blocked.<br> If the requested URL is not listed, the system checks whether it fits into a category.<br> To do this, it first checks whether this URL has already been reviewed for assignment to a category and whether this request is still in the cache.<br> If this is not the case, a request is made to the Securepoint content filter servers via the UTM, which works similar to a DNS request: The URL is first transmitted to the server. The request is answered with an IP address that informs the Webfilter in which category this URL is listed.<br> Now it is checked whether the category is listed and on a allow or blocklist. The request to this URL is then allowed or blocked.<br> It is possible that a URL is listed in several categories. The request to the content filter servers is repeated and compared with the other entries in the list.<br> If neither the URL nor a suitable category are stored in the rules, the setting under "Edit rule set" "No suitable rule found" applies. Here, a different behaviour to the default rules can be set for each rule set. If the categories are not resolvable, the behaviour set under "Edit rule set" "Category irresolvable" also applies here. }} | ||
UTM/APP/Webfilter.lang: Unterschied zwischen den Versionen
Aus Securepoint Wiki