How to Install Web Filter Lite in Untangle
Untangle Network Security (2014)
Chapter 8. Untangle Filters
This chapter will cover three other Untangle applications that are related to filtering users' traffic and the applications they use. The first application is the web filter that is used to block users' access to certain websites based on their category (social networking, games, and so on). The second application is the HTTPS Inspector, which is used to fully decrypt HTTPS traffic and pass it to applications as HTTP traffic for processing. The third application is Application Control, which is used to block users from using certain applications and protocols (BitTorrent and Facebook games, for example).
The same method that was used to explain the applications in the previous chapters will be used here; we will first introduce the application, cover how it works and any related technical details, discuss how we can review the event logs, and finally provide lab-based training. The topics that will be covered in this chapter are:
· Untangle Web Filter
· Untangle HTTPS Inspector
· Untangle Application Control
Untangle Web Filter
Web filtering is about blocking access to certain websites based on their category (Pornography, Social Media, Proxy Sites, News, and so on). Untangle provides two versions of the web filter application: the free Web Filter Lite and the paid Web Filter.
Working of Web Filter
When a user requests a website, the web filter application will send the URL of this website to a categorization database, which includes many websites and their category. The database will return the website category to the application, which will take an action (permit/deny access to this website) based on its settings.
Technical details
Untangle Web Filter Lite is based on a community-maintained database that has about 1 million websites in 15 categories and receives few updates per year, while the paid Untangle Web Filter is based on the zVeloDB URL database, which has over 500 million categorized URLs and about 5,000 categories. zVeloDB considers the de facto of web filtering and it's the first choice of many UTM vendors.
In addition, the paid version of the Untangle Web Filter surpasses the free version in the following ways:
· HTTPS Filtering: The paid version can filter the HTTPS traffic details without using the HTTPS Inspector, while the free version can't do this.
· Dynamic categorization of new websites: The paid version can block new and unknown websites, thanks to Zvelo's dynamic filtering and Distributed Intelligence Architecture (DIA), which can automatically categorize websites based on their content.
· YouTube for Schools support: The paid version allows you to access the education videos on YouTube EDU while blocking the remaining YouTube videos.
· Safe Search enforcement: The paid version can enforce safe searching on supported search engines such as Google, Yahoo!, ASK, and Bing. Safe Search is a feature on search engines that acts as an automated filter of pornography and potentially offensive content.
· The password option for the unblock feature: While the free version has the option to temporarily unblock websites for whoever requests it, the paid version can limit this unblocking to people with a certain password.
Block lists
In this section, we will review the blocking options; we can block whole categories or individual websites, and we can even block specific types of files and MIME types. The following screenshot shows the different block lists available on the paid Web Filter:
Category-based website blocking
Here, we can configure website blocking based on their category; simply check the Block and Flag checkboxes next to the desired category to block and/or flag any traffic directed to this category. By default, pornography, sex, anonymizer, and malicious websites are blocked, as shown in the following screenshot:
Untangle Web Filter has more categories than Web Filter Lite, which allows for more granular control over what to block. For example, sports is covered under one category in Web Filter Lite, which widely includes any related websites. It is covered under three categories in the paid Web Filter, which allows us to easily block animal-hunting sports websites while allowing any other sports websites, as illustrated in the following screenshot:
The Site Lookup button can be used to search for a certain website category; in addition, we can suggest the changing of the current website category. The following screenshot shows an example of www.espn.com.
Blocking individual websites
Here, we can block individual websites instead of the complete categories. For example, if we want to block only Facebook while allowing the remaining social networking websites, we can add it to the following list as shown in the next screenshot:
To add Facebook, simply press the Add button and complete the form, as shown in the following screenshot:
Blocking certain files and MIME types
In addition to blocking whole websites, we can block certain file types (for example, MP3, EXE, and so on). By default, Untangle NGFW will not block any file extension; you will be able to change this whenever you need. You can also add custom file/MIME types. The following screenshot shows the file types block list:
Allowing lists
If we want to block a whole category except for a certain website, we can use the Pass Sites list. For example, if we block the social networking category but want to allow LinkedIn, which is considered a business social networking website, we will need to add LinkedIn to the Pass List, as shown in the following screenshot:
Also, we can allow specific internal IPs to bypass the blocking list. For example, we can allow the CEO's PC to bypass any blocking rules by adding their PC's IP under the Pass Clients list as shown in the following screenshot:
This requires the CEO's PC to have a static IP. If the number of computers you want to bypass is too high, it is preferred to use the policy manager instead of the Pass Clients list.
HTTPS' advanced options
The problem with encrypted traffic is that Untangle NGFW will not have detailed information about this traffic and the destination website. Untangle Web Filter has different methods to deal with encrypted traffic in order to try to figure out what the destination website is. The following screenshot shows the advanced HTTPS options available for Untangle web Filter premium:
The first method is by using the Server Name Indication (SNI). SNI is an extension to the TLS protocol that indicates in clear text what hostname the client is attempting to connect to at the start of the TCP handshake process. SNI is supported by most of the modern web browsers and operating systems.
Note
The main purpose of SNI is to allow a single web server to host multiple secure websites. By analyzing the SNI hostname in the client request, the server can decide which SSL certificate to use to encrypt the session. This extension is necessary because the encryption must be established long before the server can ever see the HTTP request, or, it will be too late to use a different certificate.
Untangle will use the hostname listed in the SNI as the URL for the request, and all processes in this request will be done as if it were a normal HTTP traffic. So, if you requested https://www.Untangle.com/applications, Untangle Web Filter will see Untangle.com as the SNI information and will treat the request as if it was directed to http://Untangle.com. To use this method, just check the checkbox next to Process HTTPS traffic by SNI (Server Name Indication) if present.
Note
As Untangle Web Filter cannot decrypt HTTPS traffic. When a website is determined to be blocked, Web Filter will reset the connection instead of showing the block page as it can't modify the encrypting traffic.
In addition, features such as enforcing Safe Search cannot be applied because Untangle NGFW is not able to see the passed traffic.
The second method is by fetching the server name from the HTTPS server if the SNI information is not present. Web Filter will try to get the hostname from the server certificate and will complete the categorization based on this hostname. You can only use this method if the previous one doesn't work; to use it, check the checkbox next to Process HTTPS traffic by hostname in server certificate when SNI information not present.
The third method is by using the website's IP address. Sometimes, when the SNI categorization determines that the website should be blocked, this will reset the session. The web browser will retry the request; however, this time, it will not send the SNI information. Hence, Untangle NGFW will determine whether to block or allow the request based on the destination IP. However, as many websites currently use Content Delivery Networks (CDN), many undesired results may appear, such as blocking the complete CDN IP range, which has the desired block site in addition to other websites that you don't want to block, or the categorization database may have a CDN IP that is different than the CDN IP used in your area, which will result in the website being unblocked. Again, you can only use this option if the previous options don't work; just check the checkbox next to Process HTTPS traffic by server IP if both SNI and certificate hostname information are not available.
The final method is by using the HTTPS Inspector application, which will fully decrypt traffic and pass it to the web filter for processing. HTTPS Inspector gives more accurate results than the other methods and allows you to utilize the full features of Untangle Web Filter, so it's preferable to use the HTTPS inspector whenever possible as it comes free with the paid version of Untangle Web Filter.
Note
Untangle recommends that you disable the SNI detection methods when you use the HTTPS inspector.
Other advanced options
In this section, we will learn how to configure other Web Filter advanced options. The available options differ based on the version of Web Filter. The Lite version only has the Block pages from IP only hosts, Pass if referrers match Pass Sites, Block Google applications, andUnblock action menus but does not have the password for the unblock action. The full list of the available options include the following:
· Enforce YouTube for schools: YouTube for Schools allows you to limit your students' access to certain educational videos predefined by your teachers, and prohibits their access to non-educational content on Youtube. When you register for YouTube for schools, you will get a unique identifier, which defines your school to YouTube and allows YouTube to enforce your policy. You'll need to enter this identifier on Untangle NGFW for Web Filter to be able to rewrite all URLs with this identifier.
Note
When you are not using the HTTPS inspector, it may be necessary to block all YouTube HTTPS traffic that uses the application control to block encrypted access to YouTube in which Untangle NGFW will not be able to rewrite the URL.
· Enforce safe search on popular search engines: Safe Search makes search engines eliminate pornography and potentially offensive entries in the search result. This is supported by Google, Yahoo!, Bing, and Ask search engines.
· Block pages from IP only hosts: Usually, malicious websites use IP addresses instead of domain names. When this option is enabled, pages for which users enter an IP address rather than the domain name will be blocked.
· Pass if referrers match Pass Sites: An HTTP referer is an HTTP header field that identifies the address of the web page (that is the URI or IRI) that is linked to the resource being requested. By checking the referer, the new web page can see where the request originated. For example, if we have www.free4arab.com on our pass list and have www.facebook.com on the block list, when we click on a link that directs us to www.facebook.com from www.free4arab.com, the requested link will open if this option was selected.
· Block Google applications: When this option is enabled, only domains listed in domain are allowed to access Google applications such as Gmail. All other domains are blocked by Google. Multiple domains can be specified, and are separated by commas, for example,Untangle.com, domain.com.
Note
The HTTPS Inspector must be installed and running with Inspect Google Traffic configured to Inspect.
· Unblock: We can add a button to the block page to allow users to bypass it and continue their browsing. The unblocking will be on-website base and not global unblocking. The different available options are as follows:
o None: No one will be able to bypass the block page.
o Temporary: The user will get one hour access to this website.
o Permanent and Global: The website will be added to the Pass Sites list. Thus, it will be allowed for now and anytime in the future.
In addition, we can limit the unblocking to certain users who have the Untangle administrator password, or to a custom password especially for the purpose of unblocking. The following screenshot shows the Unblock functionaility:
· Clear category URL cache: When a website is requested for the first time, Web Filter will query the zVelo online database about this website category and will save the result locally to enhance the upcoming queries. This temporary local cache will automatically be cleared when it gets old or stale. However, you can clear it for testing purposes, or if you feel that the results are incorrect.
Reviewing the history
We have many ways to review the web filter scan details; the first way is the application faceplate, which indicates the total scanned pages, the number of blocked/allowed pages, and the number of pages passed based on the policy. In addition, it shows a graph of the current scan as shown in the following screenshot:
The second way is via the event logs. You can review each site's block/flag status and the reason for that (in the block list category, the file extension block list, the individual sites block list, because of using IP address, and so on) along with the details about the category and description associated with individual blocking. You can customize the fields you want to be displayed to include the timestamp, client IP, username, and so on.
You could review All Web Events, Flagged Web Events, Blocked Web Events, All HTTP Events, All HTTPS Events, and Unblocked Web Events:
The third way is through the reports application, where we can find summary reports. The available reports are as follows:
· Web Usage: This provides a summary about the average and maximum hits/violations/blocks per hour
· Total Web Usage: This shows the total number of clean hits/violations/blocked violations per day
· Top Web Browsing Hosts (by Hits): This show the top clients based on the number of sessions
· Top Web Browsing Hosts (by Size): This shows the top clients based on the traffic size
· Top Web Browsing Users (by Hits): This shows the top users based on the number of sessions
· Top Web Browsing Users (by Size): This shows the top users based on the traffic size
· Top Categories of Violations (by Hits): This shows the categories that are classified as a violation
· Top Categories of Blocked Violations (by Hits): This shows the categories that are set to be blocked
· Top Websites (by Hits): This shows the top requested websites based on the number of hits
· Top Websites (by Size): This shows the top requested websites based on the traffic size
· Top Host Violators (by Hits): This shows the top clients that request a violation category
· Top User Violators (by Hits): This shows the top users that request a violation category
· Top Violations: This shows the violated websites with the top number of hits
· Top Blocked Violations: This shows the blocked violated websites with the top number of hits
The following screenshot shows the Top Categories of Violations (by Hits) summary report:
In addition to the summary reports, there are detailed reports such as all violation events, all scan events, all visited website events, and all unblocked website events. You could export these reports as a CSV file and import them to an Excel file for extensive reviewing. The following screenshot shows the (All Events) detailed events:
Utilizing HTTPS Inspector
HTTP over SSL (HTTPS) is used to create an encrypted channel between the client and server to protect the data transferred between them; also, it allows the client to validate the authenticity of the server.
Three years ago, most websites were running in HTTP and would allow firewalls to understand and inspect passing traffic. Nowadays, most websites tend to use HTTPS by default, such as Google and Facebook, which will shift the session to HTTPS even if it was initiated using HTTP. Using HTTPS results in firewalls being unable to understand or inspect the passing traffic, which affects the firewall's functionality as some of the blocked sites could be accessed by using HTTPS. Allowing firewalls to understand the HTTPS traffic became a necessity.
Untangle and HTTPS
Untangle provides two ways to deal with HTTPS traffic; the first is to try to get details about the website without decrypting or inspecting the passing traffic. This method can get information about the website from the SNI or IP, and is available in Web Filter.
This method is very simple to deploy and maintain, and doesn't have additional administrative headaches. However, as Untangle is unable to decrypt passing traffic and is only able to get information about the websites, it will block or pass the entire website. Thus, blocking certain games on Facebook is not possible anymore, and you have to entirely block or allow Facebook.
In addition, as modifying the passing traffic is not possible, Untangle will not be able to show the blocked pages, and it will rest the HTTPS sessions instead. Also, the Safe Search and YouTube for schools features can't be used.
The second method is to make Untangle perform a man-in-the-middle style decryption and encryption of HTTPS traffic. Untangle will decrypt the HTTPS traffic, pass the decrypted traffic (HTTP) to applications and services for scanning, re-encrypt it, and then pass it to the other party. This will make Untangle maintain two separate encrypted channels: one between Untangle and the end user and the other between Untangle and the web server.
This method is very powerful and allows you to get the full details about the traffic, so you can utilize the full functionality of Untangle applications and not only the web filter, and also use the Safe Search and YouTube for schools features inside the web filter.
The downside of this method is that it requires the use of a special certificate that must be installed on all clients behind Untangle; also, the decryption and encryption of the traffic will consume more server resources. In addition, some applications with certificate hardcoded on it, such as Dropbox, won't work with this method.
Working of HTTPS Inspector
The HTTPS Inspector allows Untangle applications and services to scan the HTTPS traffic as if it was HTTP traffic.
When a client makes an HTTPS request, the HTTPS Inspector will initiate a secure SSL connection to the external server on behalf of the client. While this session is being established, the HTTPS Inspector will capture information about the SSL certificate provided by the server. Once the server session is active, the HTTPS Inspector will use the details provided on the server certificate to create a new certificate that will be used to encrypt the session between the inspector and the client.
Thus, the traffic between the external server and Untangle NGFW is encrypted using the external server certificate, and the traffic between Untangle NGFW and the client is protected by a certificate issued by Untangle CA that replicates subject information contained on the external server certificate. As the new certificate is signed by the Untangle server's internal root CA, we will need to add the Untangle server's root CA certificate to the client's trusted root CAs.
Note
Each Untangle NGFW server will have a unique root CA certificate.
Configuring clients to trust Untangle's root CA
The HTTPS Inspector is turned off by default. Once you turn it on, a warning message will appear on your browser stating that the connection is untrusted. The reason for this is the certificate generated by Untangle, which is used to encrypt the traffic between Untangle and the client, so we need to make the client trust the Untangle root CA that issues on-the-fly certificates.
The manual method
The first way is to navigate to http://<Untangle_IP>/cert, which will allow you to download and install the certificate. This method is suitable for mobile users as it simplifies the process of getting and installing the certificate; the following screenshot shows this step on Firefox. You should check the Trust this CA to identify websites checkbox and click on the OK button, as shown in the following figure:
Importing the CA certificate to Firefox will not affect Internet Explorer or Google Chrome, as Internet Explorer and Google Chrome use the Windows certificates store, while Firefox uses its own certificate store, which can be reached from the Certificate Manager menu located under Options | Advanced | certificates. The following figure shows the Firefox Certificate Manager:
The second way is to manually download and import the certificate. You can get the certificate from the HTTPS Inspector's settings by clicking on the Download Root Certificate button, or by navigating to Config | Administration | Certificates by clicking on the Download Root Certificate button, as shown in the following screenshot:
After you get the certificate, you'll need to install it; the simplest way to do this for Internet Explorer and Google Chrome is by right-clicking on the certificate and selecting Install certificate, which will open Certificate Import Wizard. From the Certificate Store page, selectTrusted Root Certification Authorities, as shown in the following screenshot. For Firefox, you will need to import the certificate to the Firefox certificate's manager:
Deploying the root CA certificate using GPO
Using a group policy to deploy the Untangle root CA will remove some headache from the IT department; however this will import the certificate to the Windows certificates' store, which will not affect Firefox.
1. First, you'll need to manually download the certificate and put it on a shared folder.
2. After that, from the group policy settings under Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies, right-click on Trusted Root Certification Authorities and then click on Import.
3. Certificate Import Wizard will be displayed; on the File to Import page, provide the certificate path, and on the Certificate Store page, click on Place all certificates in the following store. Then, finalize the wizard.
4. Now, after installing the Untangle root CA on the client PCs, when you navigate to any HTTPS website, it will be displayed as usual and no warning message will be displayed. The following screenshot shows a part of the on-the-fly certificate issued by Untangle forwww.google.com:
Configuring HTTPS Inspector
The Untangle HTTPS Inspector comes with predefined settings; it only scans traffic from certain websites with high interest, such as Facebook, YouTube, Google, and Yahoo. Any other traffic will be ignored and will not be scanned by the HTTPS Inspector. This reduces the additional resource utilization caused by the decryption and re-encryption process, and prevents the problem caused by changing the certificate for some websites and applications while maintaining the scanning for traffic with high interest such as Facebook.
Note
Some applications, such as Dropbox, have their certificate hardcoded onto the application; thus, they will never accept the on-the-fly certificate generated by Untangle. Hence, we will need to make the HTTPS Inspector ignore traffic from these types of applications.
The following screenshot shows the default rules provided by Untangle, which are considered to be a safe start for you; allowing the inspection of all traffic can be done by checking rule number 4:
Using rules for the HTTPS Inspector is similar to using rules for any other application as we already know that rules will be evaluated from top to bottom. Thus, the preconfigured rules will ignore traffic from Microsoft Update, GoToMeeting, and Dropbox, and inspect traffic from YouTube, Facebook, and so on. Any other traffic that is not listed will be ignored by rule number 13.
Tip
You should add the ignore rules before the inspect rules.
The HTTPS Inspector rules provide three new matchers that can be used to identify the traffic, which are as follows:
· HTTPS: SNI Host Name: This matches based on the provided SNI. This method is very effective as SNI is included in the initial packet of the HTTPS session.
· HTTPS: Certificate Subject: This matches any part of the certificate subject to a provided value. This method is useful when the application doesn't provide the SNI details. An example of a certificate subject for a certificate issued to Dropbox would be CN=*.dropbox.com, O="Dropbox, Inc.", L=San Francisco, ST=California, C=US.
· HTTPS: Certificate Issuer: This matches any part of the certificate issuer's distinguished name (DN) to a provided value. This method is useful when the application doesn't provide the SNI details. An example of an issuer DN that issued the certificate would be CN=Thawte SSL CA, O="Thawte, Inc.", C=US.
Creating the inspect or ignore rules is very simple; just click on the Add button, and then edit the rule to what best fits you. For example, a rule to ignore the inspecting of the Apple App Store traffic could be HTTPS: SNI Host Name is *apple.com or HTTPS: Certificate Subject is*Apple*.
Tip
The new rule will be placed at the bottom of the list. Remember to move it up before any inspect rule.
Additional HTTPS Inspector configurations located under the Configuration tab include:
· Block invalid traffic: This blocks any traffic directed to port 443 and is not HTTPS; if the HTTPS Inspector found that the traffic being directed to port 443 is not HTTPS, the default behavior is to not inspect that traffic and pass it to its destination.
Note
Remember that the HTTPS Inspector only scans HTTPS and doesn't scan any other SSL traffic such as SSL SMTP.
· Trust all server Certificates: This option allows Untangle NGFW to trust all certificates provided by external servers without checking their validity; this option is very dangerous and it's advised to not enable it. When not checked, Untangle will check the authenticity of certificates against a list of trusted CA that it has; you can add additional CAs to this list by clicking on the Upload Trusted Certificate button.
Reviewing the inspect activity
We can review the activities from the application faceplate or the application events.
The HTTPS Inspector faceplate includes a graph of the current traffic and the total number of inspected, ignored, untrusted, and abandoned sessions.
· Inspected sessions: This is determined based on your rule's settings; the inspected sessions are evaluated and scanned by Untangle applications.
· Ignored sessions: Untangle can't inspect the session. The session will continue between the server and the client without scanning from Untangle.
· Untrusted sessions: This type of session is for websites that don't provide a valid certificate or provide a certificate that is issued from CA that is not trusted by Untangle. Untangle will close the session and will not allow the client to proceed in the session unless the trust all server certificates option is checked.
· Abandoned sessions: Traffic will be blocked because of a problem of the underlying SSL, such as in the case of Dropbox.
The Event Log tab provides detailed information about the sessions; you could group sessions by all, inspected, ignored, blocked, untrusted, and abandoned. The most valued tab is the Detail (HTTPS) tab as it gives you information that can help you diagnose any problem and create suitable rules. The following screenshot shows the event log tab:
Untangle Application Control
Many modern applications are hard to block by using the port number as they are designed to avoid blocking (for example, by scanning and using any of the available open ports). Untangle Application Control deeply inspects the packets to identify the used protocol/application.
Untangle offers two versions of Application Control: the free Lite version, which is based on L7-Filter Open project, and the paid version, which is based on the PROCERA networks Network Application Visibility Library (NAVL) technology.
Note
While Untangle Application Control provides the ability to block websites, the best way to block websites is still through Web Filter. Using Application Control to block websites might not be sufficient for you.
Untangle Application Control Lite
The Lite version of the Application Control version is signature based; the signatures are regular expressions (see more on http://en.wikipedia.org/wiki/Regular_expression and http://www.regular-expressions.info/tutorial.html) that are used to match the desired protocol. An example of a signature used to block BitTorrent traffic is ^(\x13bittorrent protocol|azver\x01$|get /scrape\?info_hash=). As you see, the signatures are complex to build. In addition, it's hard to get the exact match signature. As a result, many undesired effects may appear, such as blocking legitimate traffic, and partially blocking the desired traffic; the application could also detect that it has been blocked and tries to evade this blocking and find another method for communication.
You can't add custom rules via paid Application Control, but you can do this by using Application Control Lite. You can find a signature for many protocols on http://l7-filter.sourceforge.net/protocols, and you can learn how to build an application control signature on http://l7-filter.sourceforge.net/Pattern-HOWTO. However, you need to be aware that undesired effects may appear and it's advisable to run the new signature in LOG only mode first before you start to use it in traffic blocking.
Adding Application Control Lite signatures
By default, Application Control Lite signatures are not preloaded. The user will need to go to the Wiki page to download them. This is an attempt to stop users from just enabling all signatures without understanding their side effects.
To get the Application Control Lite signatures, click on the Help button located under the Application Control Lite settings, as shown in the following figure:
This will open the Untangle Application Control Lite Wiki page; from there, under the signatures section, you'll find a warning that includes the link of the signatures (shown in the following screenshot). The direct link to the signatures ishttp://wiki.Untangle.com/images/8/8e/Application_Control_Lite_Bad_Signatures.json.
After downloading the signatures, we will need to import them to Untangle by navigating to Settings | Signatures. Click on the Import button and browse to the downloaded json file, as illustrated in the following screenshot:
After clicking on the Done button, the signatures will be imported to Untangle Application Control Lite, as shown in the following screenshot:
You will need to press OK on the display of the Import Successful message and then apply the changes.
Application Control Lite Status
The Status tab shows the total number of available signatures, how many signatures are set to be logged, and how many are set to be blocked:
Blocking applications/protocols
We can configure the applications/protocols to be logged/blocked under the Signatures tab. Simply check the Block/Log checkboxes next to the desired traffic to block and/or log this traffic. You have the option to add a custom signature, and import/export those signatures, as shown in the following screenshot:
The paid version of Application Control
The paid version of Application Control is based on the PROCERA Networks NAVL classification engine, which performs Layer 7 classification and metadata extraction of the traffic. In addition, it does deep packet and deep-flow inspection of that traffic in multilayers of the OSI model.
The classification engine uses many methods including surgical pattern matching, conversation semantics, deep protocol dissection, heuristic analysis, future flow awareness, flow association, and statistical inspection. This allows the server to accurately identify thousands of today's common applications such as social networking, P2P, instant messaging, video streaming, file sharing, enterprise applications, Web 2.0, and much more. You can find a list of the defined applications on http://wiki.Untangle.com/index.php/Application_Control_Application_List.
There are many more classified applications under paid Application Control than in Application Control Lite (1140 versus 95). The paid version of the Application Control classification is more accurate and has rare false positives, which is not the case with Application Control Lite. Also, the paid version of Application Control can easily block evading programs.
The installation of both Application Control and Application Control Lite into the same rack is supported. However, this is not the recommended action and may lead to many conflicts.
The Application Control status
The following screenshot shows the Status tab which displays the traffic scanning statistics (scanned, allowed, flagged, and blocked sessions); it also shows the total number of known applications and how many of them are set to be flagged, blocked, and tarpitted. Finally, it shows the total number of the available rules and how many of them are active:
Blocking applications/protocols
The paid version of Application Control has two ways to block applications: the first is via the Applications tab, where you can simply select the desired application, and the other way is via the Rules tab, where you cloud set rules to block more complex traffic. The Applications tab (shown in the following screenshot) is the primary and preferred way to use Application Control to manage network traffic:
Simply select the desired application and then check the desired action. The different action is Block, which will reset the session if the traffic was TCP and drop the packets if the traffic was UDP. The Log action will flag traffic as violation in the reports and event logs but will not block it. The Tarpit action will keep the session between the client and the server open but will drop all the packets.
Note
The default behavior of Application Control is to forward the initial packets of the traffic to the client until it is certain about the used application. This may result in partly-loaded websites. Some applications have the ability to quickly reinitiate the sessions if they were blocked; this will allow the websites to download another part before the session is closed again. This will appear to the user as if Application Control is not blocking anything. So, it's preferred to use the trapit action in this case as it will let the session to remain open but will drop all the packets.
In addition, Application Control has classified the applications based on their effect on the productivity and their risk. The productivity has a value from 1 to 5 where 1 represents applications that badly affect productivity, such as online gaming, while 5 represents critical applications such as Active Directory and file transfer. The same goes for the risk, where 5 represents applications that could allow malware and other malicious traffic into your network, such as bit torrent, while 1 represents top trusted traffic such as LDAP.
Tip
You can click on the description field to open a pop up for the full details of the traffic.
In addition, you can create custom rules to block complex traffic that can't be handled by the Applications tab. Application Control rules have normal rule properties such as they look for a matcher to match in the scanned traffic, and if a match is found, the defined action will be taken.
Note
The application control rules are only evaluated after the complete classification of the traffic. Thus, if the session was dropped/blocked or reset before the complete classification of the traffic, the rules will not be evaluated.
By default, there are five precreated rules that could be used to block complex traffic. The five rules are shown in the following screenshot:
Application Control introduces some new matchers. In addition to risk and productivity, it introduces the following:
· Application: This is the name of the application/protocol that creates the session (for example, GMAIL, BITTORRE, and SSL).
· Category: This is the application category (games, mail, or social networking).
· ProtoChain: This is the stack (chain) of protocols leveraged by this session to communicate, for example, /IP/TCP/HTTP/GMAIL; thus, layer 3 protocol is IP, layer 4 protocol is TCP, the application layer protocol is HTTP, and the specific application is Gmail. Additional examples are /IP/UDP/BITTORRE and /IP/TCP/SSL.
· Detail: This is a string that stores application-specific parameters that vary depending on the application. For Facebook, it will store the Facebook application name (Farmville or wordswithfriends); for HTTP, it will store the content type (image/gif); and for SSL, it will store the hostname found on the certificate (mail.google.com); review the event logs section for more clearance.
· Confidence: This represents the percentage of the engine's certainty about the traffic classification; the classification engines continue to scan the traffic until they are certain about it. Thus, short sessions may get incomplete classifications, unlike the case of long sessions. A value of 50 indicates that the classification is only done based on the source and destination address and port information, while 100 indicates that the traffic has been fully classified based on the deep inspection techniques.
Let's investigate the Block all HTTPS (encrypted) YouTube traffic rule, which is shown in the following screenshot. This rule searches for three matchers and will match if and only if all the three matchers are true. The matchers are that the traffic is TCP traffic and is directed to port 433, the PrortoChain is */YOUTUBE*, and the action to be taken is to block this traffic.
Reviewing the scanning history
As is the case with all apps, we can review the scanning and blocking history from the application's faceplate, event logs, and reports. The application's faceplate gives us a quick review of the scanning history since the last restart and also provides a graph that shows the real-time scan activity, as shown in the following screenshot:
The event logs provide more detailed information about the traffic properties such as the detected application and protocol, server ports, and client IP. The Lite version provides one event log tab that covers the scanning activity against the defined signatures while the paid version provides two event log tabs, one for the application and the other for the rules. The application event log is shown in the following screenshot. The default view for the event logs is the classified sessions. In addition, there are the blocked and flagged views. There is also an All Sessions view as some could be unclassified.
The rules event log only shows the traffic that matches any enabled rules. The following screenshot shows the traffic from blocking the YouTube rule:
The reports application provides complete event's details and a summary report. The available reports are:
· Sessions: This provides the average and maximum detections/blockage and flagging per hour.
· Top Ten Blocked Applications (by Hits): This lists the top applications based on the number of hits that caused Application Control to block the traffic.
· Top Ten Flagged Applications (by Hits): This lists the top applications based on the number of hits that caused Application Control to flag the traffic.
· Top Ten Detected Applications (by Hits): This lists the top detected applications based on the number of hits.
· Top Ten Blocked Protochains (by Hits): This lists the top protochains based on the number of hits that caused Application Control to block the traffic.
· Top Ten Flagged Protochains (by Hits): This lists the top protochains based on the number of hits that caused Application Control to flag the traffic.
· Top Ten Detected Protochains (by Hits): This lists the top detected protochains based on the number of hits.
· Top Ten Blocked Hosts (by Hits): This lists the top hosts that the traffic is blocked from.
· Top Ten Flagged Hosts (by Hits): This lists the top hosts that the traffic is flagged from.
· Top Ten Detected Hosts (by Hits): This lists the top hosts based on the number of hits detected from them.
· Top Ten Blocked Users (by Hits): This lists the top users that traffic is blocked from.
· Top Ten Flagged Users (by Hits): This lists the top hosts that traffic is flagged from.
· Top Ten Detected Users (by Hits): This lists the top users based on the number of hits detected from them.
· Top Bandwidth Applications: This lists the top applications based on their bandwidth usage.
· Top Bandwidth Protochains: This lists the top protochains based on their bandwidth usage.
The following screenshot shows the Sessions summary report:
Lab-based training
In this lab, we will learn how to utilize Web Filter, the HTTPS Inspector, and Application Control to enhance users' productivity and block undesired access to certain websites. The lab only requires two PCs and one Untangle NGFW server. This lab assumes that Web filter, Application Control, and the HTTPS Inspector are not installed in your rack.
Configuring Web Filter settings
In this section, we will start setting the configurations for Untangle Web Filter to start filtering our network traffic:
1. Install the Web filter application.
2. Under Block categories, block Social Networking.
3. Under Block Sites, add ESPN.com.
4. Under Block File types, block the exe file extension.
5. Make sure that the Enforce Safe Search on popular search engines option is selected.
6. Check the checkbox of block pages from IP only hosts.
7. Set the Unblock settings to permanent and global, check the password required checkbox, and add any custom password you want.
8. Under Pass Sites, add Linkedin.com.
9. Under Pass Clients, add the IP address of the client machine for which you don't want Web Filter to scan traffic.
Testing the functionality of Web Filter
To test Web Filter, execute the following steps:
1. Navigate to www.facebook.com, and you will not be able to initiate a session in it. You will not get the block page; instead, you will get a warning page about an invalid certificate.
2. Navigate to www.Hi5.com; this time, you'll get the block page because it's on HTTP and not HTTPS.
3. Navigate to www.LinkedIn.com. It will be allowed even though it is considered as a social networking website because we added it to the pass list.
4. Navigate to www.Espn.com. Again, you will get the block page. Let's try to permanently allow this website. By reviewing the Pass Sites list, we will find it automatically added to the list as shown in the following figure:
5. Let's get the IP address of www.ESPN.com from the event logs and try to navigate to it using this IP: 199.181.133.61. This time, access to the website will be blocked even though it is in the Pass Sites list.
6. Navigate to get.adobe.com/reader/ to download Adobe Reader. When you start the download process, you will get a block page.
7. Navigate to www.Bing.com (as it does not use HTTPS by default) and search for porn; you will get a page as shown in the following screenshot, as we have Safe Search enforced:
8. From the allowed client machine, navigate to any blocked content such as www.facebook.com; you will be allowed to access it.
Configuring HTTPS Inspector settings
Though Untangle Web Filter was able to block HTTPS traffic, we need to fully utilize its features with the HTTPS traffic such as YouTube for Schools and Safe Search on HTTPS traffic. We will need to perform the following configuration steps:
1. Disable the SNI options on Web Filter.
2. Install and enable the HTTPS Inspector.
3. Install the root CA certificate on the client computers.
4. Configure HTTPS Inspector to scan all the traffic.
5. Configure HTTPS Inspector to block invalid traffic.
Testing the functionality of Web Filter
Perform the following steps:
1. Try to download the Eicar test virus using HTTPS; this time, it will be blocked.
2. Try to navigate to www.facebook.com. This time, you'll get the block page.
3. Try to search for porn on Google (which uses HTTPS); this time, Google will apply Safe Search.
Configuring and testing Application Control settings
In this section, we will see how to configure and test the functionality of Untangle Application Control. Perform the following steps:
1. From the client PC, navigate to www.youtube.com; also try to download something via torrent clients.
2. Go to the Application Control settings, and under the Applications tab, set BITTORRE to Tarpit. Under the Rules tab, check Block all HTTPS (encrypted) YouTube traffic.
3. Now, go back to the client PC and try to navigate to www.youtube.com and resume your torrent download; they will fail and you can review this under the event logs.
4. From Web Filter, unblock Facebook for now, and under Application Control, block the FBOOKAPP.
5. Try to navigate to https://www.facebook.com/games/candycrush and select Play Now; the page will not load, and on the event log, you will see that the block was because you were trying to access the Candy Crush app.
The cat and mouse game
Since we completed our initial configurations, users started to search for ways to override our set filters. This section will cover the endless game between the network administrator and the users that want to evade the filtering.
This lab assumes that no other controls are taken by the network administrator, such as prohibiting normal users from installing applications on their PCs and blocking USB devices. However, in all the coming steps, the user is not able to get the proxy or the programs from inside the network as the proxy, anonymizer categories are blocked. The following figure shows the eventlogs for the application control when using the hidemyass proxy:
1. The user accessed www.hidemyass.com and got proxy details to use in their browser. The user will be able to access the websites they want as Web Filter will not be able to block the traffic. However, by using Application Control, the administrator will be able to classify the traffic and block it, as shown in the following figure:
2. The user tried to use Hot Spot Shield; Untangle Application Control can easily detect and block traffic from it, as shown in the following figure:
3. The user tried to use Tor; Untangle Application Control is able to detect it during the session initiation and blocks the session creation, as shown in the following figure. However, if the session is created the user can access whatever they want.
4. The user tried to use Anonymizer, which uses OpenVPN to create a VPN tunnel to a server; from there, they can access what they want. As the session will be encrypted, once created, the user will be able to access whatever they want. The administrator can detect such applications by reviewing the Application Control event log; they will notice the usage of OpenVPN on a machine that doesn't need to, as shown in the following figure:
In addition, after the session is completed, a web page to www.anonmyizer.com will be opened automatically on the client PC. Web Filter will block it, and the administrator can review it from the event logs, as shown in the following figure:
So the administrator can block using Anonymizer by blocking OpenVPN for undesired users.
5. The user tried to use UltraSurf. The old version from UltraSurf is very easy to detect and block, as shown in the following figure, while the detection of the new version is not completely possible, at the time of writing this book.
However, when the user starts to use UltraSurf, the administrator can detect it by the amount of abnormal events coming from a certain machine, such as the following events on Application Control:
6. In addition, you will find many Bad certificate Events on the HTTPS Inspector as shown in the next figure:
Summary
In this chapter, we have learned about Untangle Web Filter, the HTTPS Inspector, Application Control, Bandwidth Control, and Web Cache applications.
We saw how Web Filter and Application Control can help to increase the employee's productivity by blocking certain sites and applications. Also, we learned how to utilize the HTTPS Inspector to decrypt the HTTPS traffic and pass it as HTTP to other applications for processing.
In the next chapter, we will learn about two new Untangle applications that are used to enhance and optimize your network traffic. The first application will be Bandwidth Control that can be used to prevent certain users from draining the whole bandwidth by setting quotas. You can also limit the bandwidth assigned to certain protocols (such as BitTorrent). The second application is the Web Cache that provides a local cache of the recently visited websites. This allows the users to download the data from the local cache instead of re-downloading the data when the user re-requests this web site, which could enhance their browsing experience.
How to Install Web Filter Lite in Untangle
Source: https://apprize.best/security/untangle/9.html