Juniper JN0-230 JNCIA Security Associate – Unified Threat Management Part 2

4. Content Filtering

Welcome back. Let’s now talk about the third UTM feature known as content filtering. Content filtering provides a simple mechanism to control file transfer across the firewall. It allows you to block or permit certain types of traffic based on mime type, file extension, and protocol command. We spoke about mime types in an earlier lecture. Mime stands for “multipurpose internet mail extensions.” In simple words, it denotes the media type. It identifies the type and format of the document or file. Examples include application, image, audio, video, etc. So with content filtering, you can block or permit traffic based on the media type, file extension, and protocol commands. It can also be used to block cookies, ActiveX, Java applets, and other types of content.

Think of the extensions that you instal on the Chrome browser or the plugins or add-ons that you instal on the Firefox browser. Similarly, ActiveX is a type of plugin that you instal on the Internet Explorer browser. It doesn’t have to only be associated with Internet Explorer. There are other Microsoft products that also use ActiveX. ActiveX is known to cause security issues. Java applets are Java programmers that run within your browser.

And the security concern with Java applets is that they can be used as a mechanism to deliver malware on your computer using content filtering. File transfers can be controlled by checking traffic against configured filter lists. The interesting thing about content filtering is that it does not require a separate license. Now, let’s talk about the three mechanisms that can be configured for content filtering. The first one is the MIME filter. Like we discussed earlier, it is used to identify the type of traffic in HTTP and mail protocols like SMTP, IMAP, and POP. Three, you can define a Mime block list that contains a list of Mime-type traffic that is to be blocked.

You may also configure a Mime exception list that contains Mime patterns that are not to be blocked. The exception list has priority over the block list. Now let’s talk about the block extension list. This provides a very easy way to block or allow file transfers. The way you would do this is by defining a list of file extensions to be blocked. As an example, you can configure the blocking of exe files. The third mechanism is configuring a protocol list.

Protocols use commands to allow communication between servers and clients. This is transparent to the end user, meaning the end user does not get to see the commands that are exchanged between the server and the client. But in reality, protocols use commands to facilitate communication between servers and clients. For example, the HTTP protocol uses commands like “get,” “put,” “post,” et cetera. The FTP protocol uses commands like open, put, send, receive, quit, et cetera. So as an administrator, we can add commands to the block list or the permit list, with the permit list taking proceedings. Talking about content filtering in general, not all filtering capabilities are supported by each protocol.

The HTTP protocol supports all content filtering features. The three features that we spoke about were mimefilters, block extension lists, and protocol commands. The FTP protocol only supports block extensionlist and protocol command block list. Talking about email protocols, email protocols have limited content filtering support for block extension lists, protocol command lists, and MyPattern filtering. Email protocols include SMTP, iMapp, and POP 3. So those are the concepts for content filtering. Now let’s talk about configuration. The configuration is really simple. Step number one is to enable local content filtering on the SRX device. Step number two is to define the custom objects because we need to tell the SRX device which file extensions are to be blocked, what mine pattern needs to be blocked, or what protocol commands need to be blocked. This step is optional. Step number three is to define a feature profile.

The feature profile will reference the custom objects defined in step two. Then we’ll define a UTM policy that will reference the feature profile defined in step number three. Finally, we’ll configure the security policy to use the UTM policy. Here’s the configuration example that we’re going to use. We’ll set up a UTM policy that prevents the transfer of exe and zip files, as well as FTP commands. user, pass, send, and receive. The first two commands, user and pass, are used to log into an FTP server. Send and receive are used to send or receive a file. Now let’s get to the SRX device and see how we can configure it. All right, I’m here at the terminal of the SRX device. I’ll first navigate to the configuration mode, and from here we’ll navigate to edit security UTM. Let’s begin with a show.

So we don’t have any configuration right now. The first thing we’re going to do is define the required custom objects. So we need to block certain files based on their extensions. And we also need to block certain commands for the FTP protocol. So let’s start with a blank space and a question mark. And we are going to use the CustomObjects keyword. As a result, mark custom objects with a question mark. And here we have the different types of objects that we can define. Notice that we have all the object types that we spoke about. mime pattern, filename extension, and protocol command. First, we’ll use the file name extension keyword.

Let’s use a question mark. Here, we need to provide a name. Let’s call this “blocked files,” and let’s do a question mark. We need to provide value. We’re going to block exe and zip files, and we can configure them in a single command by using the open square bracket. We’ll say exe and zip. Close the square bracket and press Enter. Now let’s define the protocol commands. So Set custom objects (question mark) The type is “protocol command question mark.” And we need to provide a name. So let’s call this the FTP command question mark. The keyword is value, and we are going to use the open square bracket and provide all the commands at once. As a result, users must pass Send and Receive. Close the square brackets and press Enter. Let’s do a show. All right, so the custom objects have been created. Let’s also configure local content filtering using the default configuration option.

As a result, make Space Question Mark the default configuration. We know that this keyword is used to specify global configuration values. So we’ll set the default configuration content filtering type to local. We also have the option to disable it with the keyword. There is no content filtering. Press Enter. So we’ve turned on content filtering and provided the custom objects. Now we need to configure a feature profile because the SRX by itself doesn’t know what to do with these file extensions or with these FTP commands. We’ll define that in the feature profile.

So put in a question mark. The keyword is “feature profile.” We’re configuring content filtering, and the keyword is profile. And we need to provide a profile name. This is referred to as the “contentfiltering profile question mark.” We are going to use the keyword block command. Block Command: notice there are other options too, like block content type, block extension, and block mime. For the time being, we’ll use the Block command question. Mark, and we’ll call the list that we created “FTP commands.” We’ll repeat the command one more time. Set feature “Profile content filtering” “Profile name” question Mark, and this time we’ll use the block extension. keyword block extension question Mark, and we’ll call the list that we created block files. Let’s do a show.

So we have the custom objects defined, we have the default configuration, and we have a feature profile. The next step is to define a UTM policy. So put a question mark there. The keyword is UTM policy. Let’s give this a name. Let’s call it the “CF Policy” or “Content Filtering Policy.” We are defining content filtering question mark. And notice we have the option to apply different profiles for different protocols. Right now we are only going to configure FTP because we’ve only defined the commands for the FTP protocol. But if we had defined any other protocol, we could use the other options as well, like http, IMAP, pop, Three, and SMTP. So let’s use the FTP keyword, and we have the option to apply a different profile for download and upload. We’ll say “download profile,” and the profile will be called “CF Profile.” Notice that Juno also has a default content filtering profile called Juno’s CF Defaults. Let’s repeat the same command again. Create a UTM Policy Name content filtering FTP upload profiles, and we’ll provide the profile name; let’s do a show.

From a UTM perspective, the configuration looks good. Now we need to configure the UTM policy under a security policy. So we’ll go to the top and we’ll navigate to edit security policies. Let’s do a show. I already have a policy defined. So let’s do an edit from zone trust to zone untrusted policy policy name, and we’ll then use this command set and permit, and now we know that we need to use the application services keyword, and the keyword is UTM Policy, and we’ll call the content filtering policy CF Policy. Press Enter. Let’s do a show.

The configuration is looking good; we’ll go to the top and commit the configuration. If we wanted to verify the state of UTM, we could use the operational mode command run show security. UTM security question mark run UTM status, press Enter, and we can see that the UTM service is running. So that’s about configuring content filtering. The key takeaway from here is that the content filtering feature is designed to be easy to configure and easy to use to block or allow certain types of traffic. And this can be done in three ways. You can define mind patterns, extensions that need to be blocked, or protocol commands that need to be blocked. And also bear in mind that the content-filtering service does not require any additional licenses.

5. Local and Redirect Web Filtering

Welcome back. It’s now time to talk about the fourth type of UTM filtering mechanism known as “web filtering.” There are three types of web filtering. In this lecture, we’re going to talk about the first two, which are local and redirect web filtering. In the next lecture, we’ll talk about the third type of web filtering, which is enhanced web filtering. So let’s begin by talking about what web filtering is. Web filtering is a mechanism that allows you to control Internet usage.

This is very important for every organization. Controlling your Internet access allows you to control what web content is available to your employees. Web filtering makes a Block or Allow decision based on a packet’s IP address. And there are three types that we can configure on the SRX device: local web filtering, redirect web filtering, and enhanced web filtering. The first one, which is local web filtering, is a very basic form of filtering, and it is locally configured on the SRX device. The next one, which is redirect web filtering, has a few more features compared to local. And the third one, which is enhanced, is the most advanced of all three. Let’s start by talking about local web filtering.

This allows you to define custom URL categories that can be included in block lists or allow lists. Block lists and allow lists are evaluated locally on the SRX device. So you’ll start by configuring categories of URLs, and then you will tell the SRX device which category needs to be treated as a blocklist and which category needs to be treated as an allow list. And all of this is done locally on the SRX device. So each HTTP request is intercepted by the SRX device to extract the URL being accessed. The URL is then checked against the configured block list and allow list. If the URL is found in the block list, the request is denied; if the URL is found in the allow list, the request is permitted. But what happens if the URL being accessed is not found in the Block List or the Allow List? Well, in that case, the configured default fallback action will be applied. So you, as an administrator, can configure the default fallback action to be applied when a URL is accessed and that URL is not found in the Allow List or the Block List configuration.

But what happens if you don’t configure a fallback action? Well, in that case, the request will be permitted. talking about URL categories URLs can be grouped together to create categories, and this is up to you. As an administrator, you can create categories or groups of URLs in a way that makes sense to you. As an organization, it is not necessary for the URLs you’re trying to group together to be of a similar type. You can be very flexible in terms of how you want to group your URLs. A category may contain the URL or the IP address of a site, and each category can have a maximum of 20 URLs. talking about configuring local filtering. The first step is to enable the correct type of web filtering, which is Juniper Local. Then you will configure the required categories and add the required URLs. Then you’ll define a feature profile. The feature profile will tell the SRX device which categories need to be treated as allow lists and which categories need to be treated as block lists. And the feature profile also allows you to define a default action. Then you’ll define a UTM policy that references the feature profile. And finally, you’ll configure a security policy to use the UTM policy. Here’s the configuration example that we’re going to try on the SRX device. We’re going to configure a local filtering policy that blocks access to a specific URL and a specific IP address. And it also has a default action of “log” and “permit.” So if a user tries to access the URL or the IP address that we configure, the access will be blocked. But access to all other URLs will be permitted because the default action is set to log and permit.

Now let’s get to the SRX device and see how to configure it. All right, I’m here at the terminal of the SRX device. We’ll first navigate to Edit Security UTM, and we’ll begin with Show. So right now, we do not have any configuration over here. We’ll start by configuring the required type of web filtering. And the way to do that is to use the default configuration keyword. So set Default Configuration. The next keyword is Web filtering, and we’re going to use the type keyword and configure this as Juniper Local. Also notice the other types of web filtering available: Sense, Redirect, and Juniper Enhanced. So we’ll use the command Set default configuration, Web filtering; type Juniper Local; and press Enter. Next, we’re going to configure the required categories and add the URLs to them. So we’ll use the Set command and the keyword “custom objects.” And here we are trying to specify a URL pattern. So set the custom object URL pattern, and we need to provide a name for the list. Right now, let’s just call it List One, question mark. The keyword is value.

And here we can provide the requested URL or the IP address. I’m going to use the open square bracket to provide multiple values at once. First, I’ll provide the URL, which is www.example.com, and I’m also going to provide an IP address. Press Enter. Let’s do a show. So we’ve created a list called List One, and we’ve added a URL and an IP address. Next, we need to create a URL category and add the list to that category. So the command is “Set Custom Objects,” and this time we are going to use the keyword “customurl” with a question mark. And we need to provide a name. Let’s call this as Blacklist because wewant to block access to these URLs.Bear in mind that just by naming the category “blacklist,” the SRX device will not know that the URLs in this list need to be blocked. We need to tell the SRX device that the category called “blacklist” is to be used for blocking purposes. Right now, let’s complete the configuration: set custom objects, custom URL, category blacklist, and the keyword “value question mark.” And here we have the list name “listone.” Press Enter, and let’s do a show. All right, so we’ve specified the default configuration, URL pattern, and custom URL category. Now we need to configure a feature profile. Set the feature profile and the question mark accordingly. We’re configuring web filtering, and we’re configuring Juniper Local. Mark and we need to provide a profile name. Let’s call this a local profile question, Mark. and we’ll use the category keyword, category, here.

And here we can see the category that we created called “blacklist question mark.” The keyword is action, and we’re going to set this to block. That means all URLs in that category will be blocked. But we also need to allow access to the other URLs, meaning URLs that don’t belong to this category. So to do that, we’ll use the same command again to set feature profile, web filtering, Juniper, local profile, profile name, question mark, and this time we’ll use the default keyword. So this is set to default, and we’ll set this to log and permit. Let’s also configure a message that will be shown when access to the URL is blocked. So we’ll use the same command, we’ll use the uparrow and we’ll delete the last two keywords and we’ll use the keyword custom block message question mark and now we can type the message, let’s say access denied, pressEnter and let’s do a show. All right, so we’ve got custom objects, default configuration, and the feature profile configured. Next, we need to configure a UTM policy. So create a UTM policy; give it a name; call it Local Policy. We’re configuring web filtering, and you’ll notice we only have the option to configure HTTP profiles, and that’s because we are configuring web filtering.

So HTTP profile, and the profile name is “Local Profile.” Let’s do a show. So we’ve configured everything from the UTM side. Now we need to include the UTM policy in a security policy. So we’ll go to the top and navigate to edit security policies from zone Trust to zone Untrust, and we’ll enter the specific policy configuration mode. We’ll do a show here. So that’s the policy configuration. We’ll use the set command set, then permit, and we are going to invoke application services, UTM Policy, and the policy name, which is Local Policy. Let’s do a show. So the UTM policy has been configured, and that’s all there is to the configuration. We need to configure a category, put the required URLs underneath that, and tell the SRX device which category needs to be allowed and which category needs to be blocked. Now let’s talk about the second type of filtering, known as redirect filtering. Back over here. Let’s now talk about redirect web filtering. When configured, the SRX device will intercept HTTP requests, and the URL is extracted. The URL is then sent to an external WebSense server to make a permit or deny decision.

That concludes our discussion of web filtering redirection. All decisions about whether to permit or deny access to a URL are made by the Web Sense server. Bear in mind that the word “external” does not mean that the WebSense server is sitting outside your organization. In fact, the Web Sense server could be part of the same network. The word “external” in this context means that the WebSense server is a separate device from the SRX firewall. Also bear in mind that, at the time of this recording, Web Sense is a part of ForcePoint. So if you look up any online documentation about how to configure Web Sense, you may notice that it talks about forcepoint. And that’s because at this time, Web Sense is part of ForcePoint. And if you’re wondering what Web Sense is, well, Web Sense is software that can be used to control web access. So on the SRX device, you will configure the web filtering type as “redirect web filtering.” When a request comes in, the SRX device will extract the URL and send it to the Web Sense server to make a decision. So you, as an administrator, will configure all of the access rules on the Web Sense server. The Web Sense server will tell the SRX device whether to permit or deny the request.

And based on that, the SRX device will take action. Now, let’s talk about configuring redirect filtering. The first step is to tell the SRX device that the web filtering type is Web Sense Redirect. Then you will define a feature profile. In the feature profile, you’ll tell the SRX device the Web Sense server details, like the IP address and the port number. Then you’ll define a UTM policy. And then you’ll configure a security policy. To use the UTM policy, let’s get to the SRX device and take a look at the configuration. All right, back over here. Let’s configure web redirection filtering. We’ll first navigate to the Edit Security UTM page. And I’ve deleted all configuration from the stanza, so we have a blank configuration here. We’ll start with the set default configuration command, and the keyword is “web filtering.” We’ll use the type keyword and set the type as Web Sense Redirect. Next, we need to configure a feature profile. So set the feature profile for web filtering. Web sense redirect is the type. The keyword is “profile,” and we need to provide a profile name. Let’s just call it a redirect profile. And here we can configure the server details.

So the keyword is server. And to provide the IP address, we’ll use the host keyword and type in the IP address of the Web Sense server. I’m going to configure this as 192-16-8110. We can also use the port keyword to specify the port number; otherwise, it will use the default port number, which is 15868. Notice that we also have other options that we can configure, like the number of sockets and the timeout value, which by default is 15 seconds. We can also configure some other options under feature profiles, like fallback settings. What happens if the Web Sense server is not reachable or there is a connectivity problem? So we could say “set feature profile,” “web filtering,” “web sense,” “redirect profile,” “profile name,” and “question mark.” The key word is fallback settings, and we have these different options that we can configure, like what should be done if there is a server connectivity problem, what should be done if there is a timeout issue, or if we have too many requests. So we can configure the action individually for each of these situations, or we can apply a default action to all of these situations. And that’s all we need to do.

Under the feature profile, we just need to tell the SRX device the details of the server. Next, we’re going to configure the UTM policy. So now that we have the default configuration and the feature profile, let’s configure the UTM policy. So set. UTM Policy will provide a policy name. Let’s call this the Redirect Policy, QuestionMark, Web Filtering, HTTP Profile, and the profile name, which is Redirect Profile. Press Enter. And the last thing we need to do is configure the UTM policy in a security policy. So change the Zone Trust security policies to ZoneUntrust, and the policy name, as well as the commands “set” and “permit,” will invoke application services, UTM Policy, and the policy name, “Redirect Policy.” Let’s do a show here, and we’ve got that configured. So that’s about configuring redirect filtering. As you can see, the configuration is really simple, and that’s because all the decisions are made by the WebStorm server. That’s where you are going to configure all of your access rules. So with local filtering, you will configure the required categories and the URLs locally on the SRX device. And with redirect filtering, you will configure all of your access conditions and rules on the Web Sense server.

6. Enhanced Web Filtering

Let’s now talk about the third type of web filtering service, known as enhanced web filtering. With enhanced web filtering, HTTP and HTTPS requests are intercepted by the SRX device, and the URL is sent to the Web Sense threat seeker cloud, also known as TSC. It sounds like we’re talking about redirect web filtering, where the SRX device looks at the URL and forwards it to another device to make a decision. But the fact is that enhanced web filtering is completely different. Just stay with me here for a minute. So when the URL is sent to TSC, TSC is going to return the category of the URL and site reputation information. With redirect web filtering, the Web Sense server tells the SRX device what to do should access be allowed or denied. With enhanced web filtering, the thread seeker cloud does not make a decision. The Threadseeker cloud only tells the SREX device what category the URL belongs to and what its reputation score of that URL.

The administrator of the SREX device needs to determine what needs to be done for specific categories. For example, the administrator may decide that for URLs that belong to the web hosting category, access is permitted, but for URLs that belong to the gaming category, access is denied. So we see a difference here. With redirect web filtering, the web-sending server will tell the SRX device what needs to be done. With enhanced web filtering, the TSC cloud will tell the SRX device what category the URL belongs to, but what should be done for a specific category is decided by the administrator. So based on the information provided by TSC, the SRX device determines if the request can be permitted or blocked. And that’s because the administrator has configured the actions for specific categories of URLs. Before sending the URL to TSC for categorization, user-configured, block lists, and allow lists are checked.

What this means is that if you’ve locally configured Allow Lists and Block Lists on the SRX device, they will be checked first to make a decision. If the URL is not found in any locally configured list, it will be sent to TSC for categorization. But what happens if the URL belongs to a category for which the administrator has not defined an action? Well, in that case, the SRX device will permit blocking the URL based on the reputation score. So you can think of the reputation score as a fallback mechanism to make a decision when an action has not been configured for a specific category. Another question that comes up is, “What happens if we do not have an action configured for a specific reputation score?” Well, if that’s the case, meaning if global reputation is not configured, the SRX device will permit or block the URL based on the configured default action. So there are four things that we can configure. Allow and block lists can be defined locally. We can define actions for specific categories of URLs, and we can define actions for specific reputation scores. In addition, when the threat seeker cloud returns, we can configure a default action to serve as a final fallback action. Category and site reputation information for a URL is cached on the local SRX device. So if there’s another user who is trying to access the same URL, the SRX device does not have to perform another lookup. It can use the results stored in the local cache. Now, let’s talk about the site reputation information. Site reputation is a number on a scale of zero to 100. That tells the SRX device how trustworthy the URL is. If the site reputation score is between 90 and 1, the site is considered very safe. If it’s between 80 and 89, the site is considered moderately safe. If it’s between 70 and 79, the site is considered fairly safe. Between 60 and 69, the site is considered suspicious.

And for all scores between zero and 59, the site is considered harmful. Beginning in June (17), the four R-scores will be user-configurable, allowing you to tailor the reputation scores. Now let’s talk about the actions that you can configure for enhanced web filtering. Enhanced web filtering supports four actions: block,  log, permit, and quarantine actions. The first three are self-explanatory. We understand what blocked us, what log and permit do, and what allows us. But what happens when we set the action to quarantine? The quarantine action allows or denies access to a blocked site based on the user’s response to a message. Let’s talk about this. As a result, if the quarantine action is configured for a category returned by TSC, the device will lock the quarantine action. The user is shown a warning message stating that the URL is blocked according to the organization’s security policies and also prompting the user to respond. The quarantine message that is shown to the user can be customized. If the user’s response is no, the session is terminated. But if the user response is yes, the user is allowed to access the site, and the access is logged and reported to the administrator. This is very interesting.

Think about it. There could be specific categories of URLs that you want to block by default, but you also want the user to be able to override that decision in case he still needs to access that URL. So when you configure the action as quarantine, by default, access is blocked, but the user has the ability to override that and go ahead and access that website. The access is logged and also reported to the admin. Now let’s talk about configuring enhanced web filtering. The first step is to set the type of web filtering on the SRX device. In this case, we’ll configure it as Juniper-enhanced. Then you will configure the TSC server details. Then you will define a feature profile. Within a feature profile, you’ll tell the SRX device what action needs to be taken for specific categories of URLs. You will also define actions for reputation scores. Reputation scores act as a fallback mechanism. So if there is a URL that belongs to a category for which you have not configured an action, the SRX device can use the reputation score information to determine whether to permit or block the access and will also configure a default action within the feature profile.

Step number four is to define an UTM policy referencing the feature profile. And step number five is to configure a security policy that uses the UTM policy. Now let’s talk about the configuration example. So we’re going to configure an enhanced webfiltering policy that blocks URLs in the gaming and peer-to-peer file sharing categories. Allows productivity-related URLs while blocking uncategorized URLs with reputations ranging from 0 to 59 quarantines. Uncategorized URLs with a reputation of 60 to 69 log and permit URLs with a reputation of 70 or above and have a default action of quarantine. Let’s get to the SRX terminal and see how we can configure this. All right, I’m here at the terminal of the SRX device. First, we’ll navigate to Edit Security UTM, and let’s begin with showing. So we don’t have any configuration right now. We’ll first set the web filtering type to “enhanced web filtering.” And to do that, we’ll use the default configuration keyword, “set default configuration web filtering,” and the keyword we are going to use is “type question Mark,” and we’ll set it to Juniper Enhanced. Let’s do a show.

So we’ve set the type as Juniper Enhanced. Now we’ll set the actions for the different categories. And to do that, we’ll define a feature profile. For web filtering, let’s use the edit keyword edit Space questionMark feature profile and the type Juniper enhanced question mark. The keyword is “profile,” and we need to provide a profile name. Let’s call this the “EWF Profiler” or “Enhanced Web Filtering Profile.” So we’re now in the feature profile configuration mode. To set the actions for the different categories, we’ll use the category keyword. So set the Category Question Mark, and here we can see all the different categories. We need to block access to the gaming category, which can be found towards the bottom over here. So I’ll press CTRL C over here, select the category EnhancedGames question mark, and select block as the action. We’ll repeat the same thing again for the peer-to-peer file-sharing category. So set the category-enhanced peer-to-peer file sharing action block. We also need to permit access to the productivity category. As a result, set category improved. Productivity Action Question Mark And we’ll set this to permit, so press enter. Let’s do a show. So here we’ve set the actions for the categories.

Next, we need to set the actions for the different reputation scores. So we’ll begin with Mark’s setspace query and the keyword we are looking for is site. Site Reputation Action Question Mark for ReputationAction Let’s begin with harmful. This corresponds to a reputation score of 0 to 59. For this, we’ll set the action as “block.” We’ll repeat the same thing again and set aside reputation action for Suspicious, which is from 60 to 69. And this will be quarantined. We’ll repeat the same thing again for “Fairly Safe,” which is 70 to 79. and we’ll set this to log and permit. We’ll repeat it again for moderately safe, which is 80 to 89, which is also log and permit. And we’ll set the site reputation to “very safe,” which is 90 to 100. To log and permit, we’ll also set a default action. So, Mark, answer the space question. Default is the keyword. Set this to quarantine as the default. Press Enter. Let’s put on a show here so that everything looks good. Another setting that we can configure here is fallback settings. So let’s give that a try. Set fallback settings, question Mark, and we can set the action for different situations like server connectivity issues, timeout issues, or too many requests. So we can configure actions for each of these individual situations, or we can configure a default fallback action. Notice we also have the option to set the timeout.

And we also have the option to set a specific or custom quarantine message. Also notice we have this option called “No Safe Search.” Safe Search is a solution that is used to ensure that embedded objects such as images are safe and do not have any undesirable content. By default, it is turned on, but if you’d like to turn that off, you can use this keyword here called “No Safe Search.” So let’s go up a few levels. Let’s go to security UTM editing and do a show here.

So we’ve configured the default configuration as Juniper Enhanced, and we have the actions for the different categories and for the different site reputation scores. Another thing that we need to know is how to set the server details. So that’s done under the default configuration. Set the default configuration for Juniper Enhanced web filtering. Mark, and here we have the option to set the server details. Right now, I do not have a licence for Juniper Enhanced, which is why we skip that. But in a production environment, you wouldn’t need to configure that so the device knew the details of the server. Notice that you also have the option to customise the different reputation levels. All right, so now that we’ve configured the feature profile, the next thing we need to do is configure a UTM policy. So the keyword is “Set UTM policy.” We need to provide a name. Let’s call this an EWF policy question. Web filtering should be highlighted. And notice we only have one option here, httpprofile, and that’s because we are configuring web filtering.

So we went to HTTP profile, and here we can see the profile that we configured. EWF profile. Let’s do a show now. So we’ve got the type configured, we’ve got the feature profile configured, and we’ve got the UTM policy configured. The last thing we need to do is invoke the UTM policy in a security policy. So we’ll go to the configuration mode’s top and change the security policies from Zone Trust to Zone Untrust, as well as the policy name. And let’s do a show here. So this is the policy that we’re going to update. So we’ll use the command set, then permit, and we’ll invoke application services and UTM policy. And here we can see the policy name: EWF policy. Let’s do a show. And there’s the configuration. So that’s the configuration for enhanced web filtering. The key takeaway here is that with enhanced web filtering, the server is only going to return category and site reputation information. As administrators, we need to define the actions for the different categories and the different site reputation scores.