| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
Low-level packet filtering only inspects the packet headers of protocols such as IP, TCP, UDP, and ICMP. Application Layer Gateways (ALGs) can inspect at a higher OSI level.
An ALG can act as a mediator when accessing commonly used Internet applications outside the protected network, for example with web access, file transfer and multimedia transfer. ALGs provide higher security than packet filtering since they are capable of scrutinizing all traffic for a specific protocol and perform checks at the higher levels of the TCP/IP stack.
ALGs exist for the following protocols in cOS Core:
![[Note]](images/note.png) |
Note: IPv6 based traffic is not supported by some ALGs |
|---|---|
Only the HTTP (and LW-HTTP) ALGs have support for IPv6 when used with IP rule set entries that reference IPv6 addresses. |
Using IP Policies
This is the recommended method of deploying an ALG because of ease of setup and the additional features that can be applied. Some ALG features are only available when IP policies are used. In addition, some ALGs, such as the ones for DNS and IMAP, can only be deployed using IP policies.
Note that a requirement with this method is that the Service property of the IP policy is assigned a service object which has its Protocol property set to the ALG type (for example, "FTP"). It is usually preferable to create a custom service object for this purpose, although in some cases a predefined service could be used.
Using IP Rules
With this method, an ALG object for the specific protocol is assigned to a Service object which is in turn assigned to an IP rule. This method of ALG deployment is usually only needed for compatibility with older versions of cOS Core.
Predefined ALG objects exist which could be used with IP rules but it is usually better to create a custom ALG object.
This section includes details for setting up ALGs using all the available methods.
Setting the Maximum Sessions Properties for a Protocol
The service object used with either an IP Rule (when deploying an ALG) or an IP Policy has two properties called ALG Max Sessions and Protocol Max Sessions. These properties set the maximum number of allowed connections across all interfaces that can be handled by a single service object. The default values for these properties can vary according to the service's protocol. Two similar properties exist for each service object because one is used with IP rules and the other is used with IP policies (when the service's Protocol property is also set). Often, these properties will have the same value. For example, both properties for the predefined http-all service have the default value of 200. This means that a total of 200 connections are allowed for HTTP/HTTPS across all interfaces.When the numbers of connections for a given protocol exceeds the relevant Max Sessions value, further connection attempts are dropped and a protocol specific log message is generated to indicate this. For example, the max_http_sessions_reached log message will indicate this condition for HTTP/HTTPS.
HTTP is an example of a protocol where the default Max Sessions value may need to be increased if a large number of HTTP/HTTPS clients are being processed by a given service object. The following are some guidelines for setting the maximum value based on the protocol:
For the HTTP/HTTPS, TLS and DNS: Number of users x 20 + 500 (with a minimum value of 2000).
For all other protocols: Number of users x 2 (with a minimum value of 500).
For example, if the potential HTTP/HTTPS concurrent users are estimated to be one thousand, the recommended Max Sessions value for this protocol (for either IP rules or IP policies) would be: 1,000 x 20 + 500 = 20,500.
ALG Changes From cOS Core Version 11.01 Onwards
From cOS Core version 11.01 onwards, many of the predefined ALG objects have been removed from a new installation of cOS Core. Upgrading from an older cOS Core will not change the predefined ALG objects and a new installation can manually recreate any missing ALGs if required.With cOS Core version 11.01 and later, it is possible to avoid using most ALG objects directly. This is achieved by using IP Policy objects in place of IP Rule objects. From 11.01 onwards, most predefined Service objects can be used directly with an IP policy and all of the properties previously available in the ALG object will become properties of the IP Policy object. However, the Protocol property of a Service object should be set appropriately when it is used with an IP policy in order for the corresponding ALG to be available with that policy.
This topic is also discussed in Section 3.3, Services.
Hyper Text Transfer Protocol (HTTP) is the primary protocol used to access the World Wide Web (WWW). It is a connectionless, stateless, application layer protocol based on a request/response architecture.
A client, such as a web browser, sends a request by establishing a TCP/IP connection to a known port (usually port 80) on a remote server. The server answers with a response string, followed by a message of its own. That message might be, for example, an HTML file to be shown in the Web browser or an ActiveX component to be executed on the client, or perhaps an error message.
The HTTP protocol has particular issues associated with it because of the wide variety of websites that exist and because of the range of file types that can be downloaded using the protocol.
Limitations with HTTPS
With HTTPS, the traffic is encrypted and the HTTP ALG can therefore only perform the following actions on the traffic:
URL filtering.
Web content filtering.
User-agent filtering (denying or allowing certain browser versions).
This should be kept in mind when the service used with the IP rule set entry filter includes HTTPS (for example, when using the http-all service).
The HTTP ALG Provides IPv6 Support
The HTTP ALG can be used with IP Rule objects that reference IPv6 addresses and networks. Similarly, IPv6 based IP Policy objects can also make use of the features of these ALGs (the ALG object is hidden when using an IP Policy).The Ordering for HTTP Filtering
HTTP filtering obeys the following processing order and is similar to the order followed by the SMTP ALG:As mentioned, if a URL is in the whitelist, it will not be blocked if it is also in the blacklist.
Methods of Setting Up the HTTP ALG
Deploying the HTTP ALG can be done using one of the following methods:Using an IP Policy
Some HTTP ALG options can then be configured directly on an IP policy but most are configured by associating a Web Profile object with an IP policy. This is described further in Section 6.1.2.2, HTTP ALG Setup With IP Policies.
Note that the IP policy must have its Service property assigned a service object which has its Protocol property set to HTTP.
Using an IP policy is the recommended way to deploy the HTTP ALG.
Using an IP Rule
With this method, an HTTP ALG object is associated with a Service object that is then itself associated with an IP rule. All the ALG options are configured directly on the HTTP ALG object. This is described further in Section 6.1.2.4, HTTP ALG Setup With IP Rules.
The HTTP ALG options are configured on an IP Policy object with the following steps:
The Service property of the IP policy must be set to a service object that has its Protocol property set to one the following values depending on the traffic targeted:
For HTTPS, the Service must include the port number 443 for HTTPS.
Set the values for any of the HTTP ALG settings which are directly configurable on the IP policy. These are discussed later.
Create a Web Profile object and associate this with the IP policy. This profile will allow many ALG features such as web content filtering and URL filtering to be configured.
Associate any other relevant objects with the IP policy. For example, a File Control Profile could be created and linked with the IP policy to impose restrictions on any files downloaded using HTTP.
HTTP ALG Options Directly Configurable on an IP Policy
The following options can be directly configured on an IP policy:Enable HTTP Inspection
The ALG will check that the HTTP traffic is valid HTTP. This includes checking that URLs do not include invalid UTF8 encoding. This is disabled by default.
Allow Unknown Protocols
Non-HTTP compliant traffic will be allowed. This is disabled by default.
Name
A logical name for the object in the configuration.
Allow Protocol Upgrade
This allows the HTTP connection to be upgraded to another protocol. For example, to HTTPS. The default is to allow this.
Fail Mode
What action to take should there be an error in cOS Core processing. For example, the WCF databases might become unreachable. The default is Allow which means nothing is blocked.
User-Agent Filter Mode
Specific browsers and/or browser versions can be allowed and all others blocked using this property. This is configured by adding User-Agent objects as children to the Web Profile object associated with the filtering IP Policy. This feature is discussed further in Section 6.1.2.3, User Agent Filtering.
HTML Banner
This selects which HTML banner file to use for displaying to HTTP clients when access is denied.
Web Content Filtering
This enables web content filtering (WCF). By default this is disabled. Web content filtering is discussed further in Section 6.2, Web Content Filtering.
URL Filters
Specific URLs can be whitelisted (all checks are skipped) or blacklisted (the connection is dropped). This is done by adding one or more URL objects as children to a Web Profile object. URLs can be specified using wildcards and this is discussed further at the end of this section.The URL Filter object has two key properties, the URL itself and the Action which can take one of the following values.
Blacklist
Attempts to reach the URL are dropped.
Whitelist
The URL is always accessible and no further ALG checks are performed.
It is important to note that whitelisting means that a URL cannot be blacklisted and it also cannot be dropped by web content filtering (if that is enabled, although it will be logged). Anti-Virus scanning, if it is enabled, is also not applied to HTTP traffic from a whitelisted URL.
Redirect
The URL will automatically be redirected to a second URL which can be specified in the web profile. This second URL can optionally contain any combination of the following variables:
%CLIENT_IP% - The IP address of the connecting client.
%CLIENT_MAC% - The MAC address of the connecting client.
%CLIENT_IFACE% - The receiving interface.
%ORG_URL% - The original URL (URL encoded).
%DEVICE_NAME% - The device name of the firewall performing the redirect.
An example URL specified in the web profile might be:
https://www.test.com/http_params.php?client=%CLIENT_IP%&url=%ORG_URL%
URL redirection has the same precedence as blacklisting. In other words, whitelisting takes priority and any redirection for the same URL is ignored. If the same URL is subject to both blacklisting and redirection because of an administrator mistake then one of them will be chosen at random as the action to perform.
URL redirection loops are discussed later in this section. It is often advisable to whitelist the new URL so these cannot occur.
Whitelist and Blacklist Processing Precedence
Whitelisting always takes precedence over blacklisting. If, by mistake, the same URL is both blacklisted and whitelisted, the blacklisting action will be ignored because whitelisting is always processed first.Precedences with Multiple URL Matches
When specifying URLs using wildcards, the possibility exists there can be more than one filter that matches a given URL. It should be noted that cOS Core does not choose the narrowest match. The action of the first match encountered will be taken and no further searching of the filters will occur. Whitelisted and blacklisted URLs can make use of wildcarding to have a single entry be equivalent to a large number of possible URLs. The wildcard character "*" can be used to represent any sequence of characters.For example, the entry *.example.com will block all pages whose URLs end with example.com.
If we want to now explicitly allow one particular page then this can be done with an entry in the whitelist of the form my_page.example.com and the blacklist will not prevent this page from being reachable since the whitelist has precedence.
Wildcard Examples
Below are some good and bad blacklisted example URLs that include wildcards:Only the Domain Level Can Be Targeted With HTTPS Traffic
Due to the encrypted nature of HTTPS, it is only possible to whitelist or blacklist at the domain level. For example, only the form *.example.com/* can be used for blacklisting or whitelisting with HTTPS. Using the form *.example.com is insufficient.If *.example.com/server is specified for HTTPS traffic, this will not work and the matching URLs will not be caught.
Black/whitelisting Takes Precedence Over Web Content Filtering
Blacklisting and whitelisting occurs before web content filtering. This provides the possibility of manually making exceptions from the WCF process. In a scenario where goods have to be purchased from a particular online store, WCF might be set to prevent access to shopping sites by blocking the "Shopping" category. However, whitelisting the online store's URL means that the URL is always allowed, taking precedence over dynamic content filtering.Similarly, a static content filter that blacklists a URL means that URL will never reach dynamic content filtering.
URL Filtering Setup Using an IP Policy
When enabling URL filtering using an IP Policy object, a different set of objects is used. The setup steps are the following:Create a Web Profile object.
Add one or more URL Filter objects as children of the Web Profile to define URLs that are whitelisted or blacklisted. Wildcarding can be used when specifying the URLs.
A third URL filtering option that is available only with the Web Profile object is to specify a redirect URL. In this case, cOS Core will cause a redirection of the triggering URL to the specified redirect URL. Whitelisting of the new URL may be needed and when to do this is explained later in this section.
Create a new Service object for HTTP and/or HTTPS. A predefined object could be used for this purpose. This Service object must have its Protocol property set to be HTTP, HTTPS or HTTP and HTTPS. For HTTPS, the Service must include the port number 443 for HTTPS.
Use the Service object with an IP policy that filters the relevant traffic.
Set the Web Profile property of the IP Policy to the profile created earlier.
URL Redirection and Avoiding Redirection Loops
An important consideration when using URL redirection is the possible need to whitelist the new URL so that looping does not occur. This is because after URL substitution, the new URL is again checked against the URL filters. The following example will illustrate the problem.Suppose a URL Filter object is created that specifies the triggering URL to be the wildcard character *. This means that any URL will trigger the filter. Suppose that the redirect option is chosen for this filter and the redirect URL is specified as www.example.com. When the substitution is performed, the new URL www.example.com will again be looked up against the filters and again will trigger in the same way, creating a loop. If www.example.com is first explicitly whitelisted in another then it can't trigger any filters and the loop is avoided.
Suppose instead that the URL Filter object triggers on the URL www.anotherexample.com and this is redirected to www.example.com. In this case, whitelisting of www.example.com would not be needed if that URL did not trigger another URL Filter object.
Example 6.1. URL Redirection with an IP Policy
This example illustrates how static content filtering is used with an IP policy to achieve URL redirection. The URL www.anotherexample.com is redirected to the URL www.example.com for a pre-existing IP Policy object called my_web_profile.
Command-Line Interface
Create a new WebProfile object:
![[Important]](images/important.png)
Device:/> add Policy WebProfile my_web_profileChange the CLI context to be the profile:
Device:/> cc Policy WebProfile my_web_profileThen add a filter as a child of the profile:
Device:/my_web_profile> add URLFilterPolicy_URL
URL=www.anotherexample.com
Action=Redirect
RedirectTo=http://www.example.comReturn to the default context:
Device:/my_web_profile>ccDevice:/>
Associate the profile with the relevant IP policy:
Device:/> set IPPolicy my_ip_policy
WebControl=Yes
Web_Policy=my_web_profile
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new WebProfile object:
Add a URL filter:
Associate the web profile with the relevant IP policy:
When configuring an IP Policy object, specific web browsers and/or browser versions can be allowed or blocked using the User Agent Filter Mode property in the Web Profile associated with the IP Policy.
In the HTTP protocol, the User-Agent field identifies the client software that is involved in an HTTP interaction. For many HTTP interactions this is a web browser. For example, the User-Agent field generated by the Firefox™ browser might look like the following:
Mozilla/5.0(Windows NT 10.0; Win64; x64; rv:70.0)Gecko/2010010 Firefox/70.0
The network administrator may want to deny or allow certain web browsers or browser versions because they pose a security risk or because others are preferable. cOS Core can examine the User-Agent field as HTTP traffic traverses the firewall and allow or deny access to agents which match a specified string or set of strings.
Setting Up User-Agent Filtering
When using IP Policy objects for HTTP filtering, user-agent filtering is configured by adding one or more User-Agent Filter objects as children to a Web Profile associated with the policy. Typically, each filter will target a specific web browser, such as Firefox or Chrome.Each filter object specifies a single string and the filter will trigger if the string matches an HTTP connection's User-Agent field. The behavior on triggering is determined by the User-Agent Filter Mode property of the Web Profile. The User-Agent Filter Mode property can be set to one of the following values:
Deny Selected - Only the agents specified by the filter(s) will be denied. All other agents will be allowed. This is the default setting.
Allow Selected - Only the agents specified by the filter(s) will be allowed. All other agents will be denied.
However, if no User Agent Filter objects are added to the Web Profile, all user-agents will be allowed, regardless of the setting for the mode.
Using Wildcards
As can be seen from the agent example above for Firefox, the entire agent string can be long. It can therefore be better when specifying the agent string in a filter to use wildcards. The following wildcards are available:The asterisk "*" character represents any string.
The question mark "?" character represents any single character.
For example, if only Firefox browser was to be allowed, a single filter could be added with the following string:
*Firefox/*
User Feedback on Blocking
If cOS Core blocks a browser then the HTTP connection is not simply dropped. Instead, the user will get back a single webpage from cOS Core that informs them that the user-agent is not valid. This webpage cannot be changed by the administrator.Filtering the User-Agent with IP Rules
When filtering the user-agent with an IP Rule object instead of an IP Policy, the LW-HTTP ALG must be associated with the rule via a suitable HTTP service. The User Agent Filter objects are then added as children to the ALG and are configured in the way described above. The action on triggering is also set in the ALG object.Example 6.2. User-Agent Filtering with an IP Policy
This example shows how a User-Agent Filter is added to a new Web Profile object to deny access to Firefox browsers with the number "31" in the user-agent string.
Command-Line Interface
Create a new WebProfile object:
Device:/> add Policy WebProfile my_web_profile UserAgentMode=DenySelectedAdd a UserAgentFilter to the profile:
Device:/>cc WebProfile my_web_profileDevice:/my_web_profile>add UserAgentFilter UserAgent=*firefox*31*
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new Web Profile object:
Add a User-Agent Filter to the profile:
This section looks at how the HTTP can be deployed using an HTTP ALG object directly with IP rules. This section is not applicable if IP policies are used to deploy the HTTP ALG.
Using an HTTP ALG Object with IP Rules
An HTTP ALG object is brought into use by first associating it with a service object and then associating that service object with an IP rule in the IP rule set. A number of predefined HTTP services could be used with the ALG. For example, the http service might be selected for this purpose. As long as the associated service is associated with an IP rule then the ALG will be applied to traffic targeted by that IP rule.The Light Weight HTTP ALG Alternative
This section describes the standard HTTP ALG. In many situations the alternative Light Weight HTTP ALG (LW-HTTP ALG) can be a better choice since it requires less hardware resources and can provide higher traffic throughput. When using IP Policy objects the LW-HTTP ALG is used automatically when required. However, the stripping of static content and HTTPS processing are not available with the LW-HTTP ALG.More information about the LW-HTTP ALG and the differences between the two ALGs can be found in Section 6.1.2.5, Light Weight HTTP ALG.
HTTP ALG Object Features
An HTTP ALG object provides the following options:Active Content Handling
The optional blocking of any of the following is possible:
ActiveX objects can be stripped from web pages, including Flash.
Java applets can be stripped from webpages.
Javascript and Visual Basic Scripts can be stripped from webpages.
Website cookies can be blocked.
Note that active content handling is not available when configuring the HTTP ALG with IP policies.
![[Caution]](images/caution.png) |
Caution: Consider the consequences of removing objects |
|---|---|
|
Careful consideration should be given before enabling removal any object types from web content. Many websites use Javascript and other types of client-side code and in most cases, the code is non-malicious. Common examples of this is the scripting used to implement drop-down menus as well as hiding and showing elements on web pages. Removing such legitimate code could, at best, cause the website to look distorted, at worst, cause it to not work in a browser at all. Active Content Handling should therefore only be used when the consequences are well understood. |
Some attacks can take the form of malformed URLs containing invalid encoding. Enabling this option will mean that the ALG checks for malformed URLs.
A number of checks can be made on any files downloaded via HTTP. These are:
File Size - A file size limit can be specified for any single download (this option is only available for HTTP and SMTP ALG downloads).
File Type Policy - It is possible to allow specific file types or to block specific file types.
Allow/Block Selected Types
This option operates independently of the MIME verification option described above but is based on the predefined filetypes listed in Appendix C, Verified MIME filetypes. When enabled, the feature operates in either a Block Selected or an Allow Selected mode. These two modes function as follows:
i. Block Selected
The filetypes marked in the list will be dropped as downloads. To make sure that this is not circumvented by renaming a file, cOS Core looks at the file's contents (in a way similar to MIME checking) to confirm the file is what it claims to be.
If, for example, .exe files are blocked and a file with a filetype of .jpg (which is not blocked) is found to contain .exe data then it will be blocked. If blocking is selected but nothing in the list is marked, no blocking is done.
ii. Allow Selected
Only those filetypes marked will be allowed in downloads and others will be dropped. As with blocking, file contents are also examined to verify the file's contents. If, for example, .jpg files are allowed and a file with a filetype of .jpg is found to contain .exe data then the download will be dropped. If nothing is marked in this mode then no files can be downloaded.
Additional filetypes not included by default can be added to the Allow/Block list however these cannot be subject to content checking meaning that the file extension will be trusted as being correct for the contents of the file.
Verify MIME Type
This option enables checking that the filetype of a file download agrees with the contents of the file (the term filetype is sometimes called the filename extension).
All filetypes that are checked in this way by cOS Core are listed in Appendix C, Verified MIME filetypes. When enabled, any file download that fails MIME verification, in other words its filetype does not match its contents, is dropped by cOS Core on the assumption that it can be a security threat.
Web Content Filtering
Access to specific URLs can be allowed or blocked according to policies for certain types of web content. Access to news sites might be allowed whereas access to gaming sites might be blocked. This feature is described in depth in Section 6.2, Web Content Filtering.
The contents of HTTP file downloads can be scanned for viruses. Suspect files can be dropped or just logged. This feature is common to a number of ALGs and is described fully in Section 6.4, Anti-Virus Scanning.
URL Filtering
The administrator can define the blacklisting and whitelisting of specific URLs. This is done by adding one or more HTTP ALG URL objects as children of a single parent HTTP ALG object.
Specific URLs can be blacklisted so that they are not accessible. Wildcarding can be used when specifying URLs.
The opposite to blacklisting, this makes sure certain URLs are always allowed. Wildcarding can also be used for these URLs.
It is important to note that whitelisting a URL means that it cannot be blacklisted and it also cannot be dropped by web content filtering (if that is enabled, although it will be logged). Anti-Virus scanning, if it is enabled, is also not applied to HTTP traffic from a whitelisted URL.
Using wildcards when specifying URLs is discussed in Section 6.1.2.2, HTTP ALG Setup With IP Policies.
Example 6.3. Stripping ActiveX and Java applets
This example shows how to configure a HTTP Application Layer Gateway to strip ActiveX and Java applets. The example assumes that the ALG object content_filtering has already been created previously.
Command-Line Interface
Device:/> set ALG ALG_HTTP content_filtering
RemoveActiveX=Yes
RemoveApplets=YesInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
URL Filtering Setup Using an IP Rule
The following steps should be used for setting up URL filtering with an IP rule:Create an HTTP ALG object. For HTTPS traffic, set the Allowed Protocol property to be HTTPS.
Add one or more HTTP ALG URL objects as children of the ALG to define the URLs that are whitelisted or blacklisted.
Note that redirection cannot be performed when using an IP rule and requires a Web Profile object associated with an IP Policy object, as described later in this section.
Use this ALG in a Service object. The service object could be an existing or created object that allows HTTP and/or HTTPS traffic. For HTTPS, the service must include the port number 443.
Associate the service object with an IP Rule object that has the appropriate filters set to trigger on the target traffic.
Example 6.4. URL Filtering Setup Using an IP Rule
This example shows the use of static content filtering where certain URLs are to be blacklisted and others whitelisted. This example also illustrates the use of wildcards to prevent the downloading of a specific filetype.
Assume that HTTP clients are to be prevented from downloading .exe files from any website using blacklisting with wildcards. However, .exe files downloaded from the www.example.com website are to be an exception to this rule and will be whitelisted.
Command-Line Interface
Begin by creating an HTTP ALG for HTTP traffic:
Device:/> add ALG ALG_HTTP my_content_filterChange the CLI context to be the ALG:
Device:/> cc ALG ALG_HTTP my_content_filterThen add an HTTP ALG URL as a child to blacklist a URL:
Device:/my_content_filter> add ALG_HTTP_URL
URL=*/*.exe
Action=BlacklistMake an exception from the blacklist by adding a whitelisted URL:
Device:/my_content_filter> add ALG_HTTP_URL
URL=www.example.com/*.exe
Action=WhitelistIf no more filters are to be added, return back to the default CLI context:
Device:/my_content_filter>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Start by adding an HTTP ALG in order to filter HTTP traffic:
Then create a HTTP ALG URL to set up a blacklist:
Finally, make an exception from the blacklist by creating a whitelist:
|
Note: Skip this section if using IP Policies |
|---|---|
|
Understanding the LW-HTTP ALG is only necessary when configuring HTTP ALG processing with IP Rule objects. This section can be skipped when IP Policy objects are used instead to filter HTTP traffic. |
The Light Weight HTTP ALG (LW-HTTP ALG) provides an alternative to the standard HTTP ALG when configuring the HTTP ALG using IP rules. If using IP policies, the LW-HTTP ALG will be deployed automatically when required so this section can be skipped. This section is only relevant if IP rules are being used for ALG deployment.
LW-HTTP ALG Advantages
The LW-HTTP ALG can provide the following key advantages over the standard HTTP ALG:Gives higher throughput performance than the standard HTTP ALG.
Consumes much less memory than the standard HTTP ALG. This allows cOS Core to support a much greater number of concurrent connections.
Can perform certain functions that the standard HTTP ALG cannot perform. These are listed next.
Functions that Only the LW-HTTP ALG Can Perform
The following functions are only available in the LW-HTTP and do not exist in the standard HTTP ALG:User Agent Filter Support - Specific browsers and/or browser versions can be allowed and all others blocked. This is configured by adding User-Agent objects as children to the LW-HTTP ALG. This feature is discussed further in Section 6.1.2.3, User Agent Filtering.
Protocol Upgrade Support - The LW-HTTP ALG allows the protocol to be changed. For example, to the Web Sockets protocol.
Functions the LW-HTTP ALG Cannot Perform
The following functions cannot be provided by the LW-HTTP and can only be provided by the standard HTTP ALG:The LW-HTTP ALG does not support HTTPS traffic.
The LW-HTTP ALG cannot modify a stream of HTTP data as it passes through the firewall. For this reason, the following static filtering cannot be performed:
Anti-Virus scanning is only supported when the LW-HTTP ALG is used with an IP Policy object. It cannot be used for anti-virus scanning with an IP Rule object.
File control is only supported when the LW-HTTP ALG is used with an IP Policy object. It cannot be used for file control with an IP Rule object.
Example 6.5. Using the Light Weight HTTP ALG
This example shows how to set up a Light Weight HTTP (LW-HTTP) ALG for clients that are surfing the web using HTTP from a protected network to the Internet. It will be configured to allow only the Firefox and Chrome browsers (all other browsers will be denied). In addition, protocol upgrading will be allowed.
It is assumed that a single NAT IP rule is already configured which allows traffic from the internal network to the Internet. This rule is called int_to_ext_http
Command-Line Interface
First, create an LW-HTTP ALG object:
Device:/> add ALG ALG_LWHTTP my_lw_http_alg
AllowProtocolUpgrade=Yes
UserAgentFilterMode=AllowSelected
Change the CLI context to be the new ALG:
Device:/> cc ALG ALG_LWHTTP my_lw_http_algAdd the User-Agent filter that will allow Firefox:
Device:/my_lw_http_alg> add ALG_HTTP_UA UserAgent=*Firefox/*Add the User-Agent filter that will allow Chrome:
Device:/my_lw_http_alg> add ALG_HTTP_UA UserAgent=*Chrome/*Return to the default CLI context:
Device:/my_lw_http_alg>ccDevice:/>
Now, create a service object and associate it with this new ALG:
Device:/> add Service ServiceTCPUDP my_http_service
Type=TCP
DestinationPorts=80
ALG=my_lw_http_alg
Finally, modify the NAT IP rule to use the new service.
Device:/> set IPRule int_to_ext_http Service=my_http_service
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First, create an LW-HTTP ALG object:
Edit the LW-HTTP ALG just created:
Now, create a service object and associate it with this new ALG:
Finally, modify the NAT IP rule to use the new service:
Overview
File Transfer Protocol (FTP) is a TCP/IP-based protocol for exchanging files between a client and a server. The client initiates the connection by connecting to the FTP server. Normally the client needs to authenticate itself by providing a predefined login and password. After granting access, the server will provide the client with a file/directory listing from which it can download/upload files (depending on access rights). The FTP ALG is used to manage FTP connections through the Clavister firewall.A general discussion of using cOS Core with FTP and its more secure variants, FTPS and SFTP, can be found in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735941
FTP Connections
FTP uses two communication channels, one for control commands and one for the actual files being transferred. When an FTP session is opened, the FTP client establishes a TCP connection (the control channel) to port 21 (by default) on the FTP server. What happens after this point depends on the FTP mode being used. FTP operates in two modes: active and passive. These determine the role of the server when opening data channels between client and server.Active Mode
In active mode, the FTP client sends a command to the FTP server indicating what IP address and port the server should connect to. The FTP server establishes the data channel back to the FTP client using the received address information.
Passive Mode
In passive mode, the data channel is opened by the FTP client to the FTP server, just like the command channel. This is the often recommended default mode for FTP clients although some advice may recommend the opposite.
A Discussion of FTP Security Issues
Both active and passive modes of FTP operation can present problems. Consider a scenario where an FTP client on the internal network connects through the firewall to an FTP server on the Internet. The IP rule is then configured to allow network traffic from the FTP client to port 21 on the FTP server.When active mode is used, cOS Core does not know that the FTP server will establish a new connection back to the FTP client. Therefore, the incoming connection for the data channel will be dropped. As the port number used for the data channel is dynamic, the only way to solve this is to allow traffic from all ports on the FTP server to all ports on the FTP client. Obviously, this is not a good solution.
When passive mode is used, the firewall does not need to allow connections from the FTP server. On the other hand, cOS Core still does not know what port the FTP client will try to use for the data channel. This means that it has to allow traffic from all ports on the FTP client to all ports on the FTP server. Although this is not as insecure as in the active mode case, it still presents a potential security threat. Furthermore, not all FTP clients are capable of using passive mode.
The cOS Core ALG Solution
The cOS Core FTP ALG deals with these issues by fully reassembling the TCP stream of the FTP command channel and examining its contents. By doing this, the cOS Core knows what port to open for the data channel. Furthermore, the FTP ALG also provides functionality to filter out certain control commands and provide buffer overrun protection. An important feature of the cOS Core FTP ALG is its automatic ability to perform on-the-fly conversion between active and passive mode so that FTP connection modes can be combined. Passive mode can be used on one side of the firewall while active mode can be used on the other. This type of FTP ALG usage is sometimes referred to as hybrid mode.The advantage of hybrid mode can be summarized as follows:
The FTP client can be configured to use passive mode, which is the recommended mode for clients.
The FTP server can be configured to use active mode, which is the safer mode for servers.
When an FTP session is established, the firewall will automatically and transparently receive the passive data channel from the FTP client and the active data channel from the server, and correctly tie them together.
This implementation results in both the FTP client and the FTP server working in their most secure mode. The conversion also works the other way around, that is, with the FTP client using active mode and the FTP server using passive mode. The illustration below shows the typical hybrid mode scenario.
|
Note: Hybrid conversion is automatic |
|---|---|
|
Hybrid mode does not need to be enabled. The conversion between modes occurs automatically within the FTP ALG. |
Connection Restriction Options
The FTP ALG has two options to restrict which type of mode the FTP client and the FTP server can use:Allow the client to use active mode.
If this is enabled, FTP clients are allowed to use both passive and active transfer modes. With this option disabled, the client is limited to using passive mode. If the FTP server requires active mode, the cOS Core FTP ALG will handle the conversion automatically to active mode.
A range of client data ports is specified with this option. The server will be allowed to connect to any of these if the client is using active mode. The default range is 1024-65535.
Allow the server to use passive mode.
If this option is enabled, the FTP server is allowed to use both passive and active transfer modes. With the option disabled, the server will never receive passive mode data channels. cOS Core will handle the conversion automatically if clients use passive mode.
A range of server data ports is specified with this option. The client will be allowed to connect to any of these if the server is using passive mode. The default range is 1024-65535.
These options can determine if hybrid mode is required to complete the connection. For example, if the client connects with passive mode but this is not allowed to the server then hybrid mode is automatically used and the FTP ALG performs the conversion between the two modes.
Predefined FTP ALGs and Services Before cOS Core Version 11.01
In older versions of cOS Core, four predefined FTP ALG and Service objects were provided, each with a different combination of client/server mode restrictions. These ALG and Service objects had the following names:ftp-inbound - Clients can use any mode but servers cannot use passive mode.
ftp-outbound - Clients cannot use active mode but servers can use any mode.
ftp-passthrough - Both the client and the server can use any mode.
ftp-internal - The client cannot use active mode and the server cannot use passive mode.
Beginning with cOS Core version 11.01, these individual services are removed from a new cOS Core installation. However, they remain in configurations that upgrade to 11.01 or later. A new installation can recreate them manually but the recommended option is to use the predefined ftp service with an IP Policy object, in which case all the options previously available on the ALG are now available directly on the policy.
The FTP protocol consists of a set of standard commands that are sent between server and client. If the cOS Core FTP ALG sees a command it does not recognize then the command is blocked. This blocking must be explicitly lifted and the options for lifting blocking are:Allow unknown FTP commands. These are commands the ALG does not consider part of the standard set.
Allow the SITE EXEC command to be sent to an FTP server by a client.
Allow the RESUME command even if content scanning terminated the connection.
Maximum line length in control channel
Creating very large control channel commands can be used as a form of attack against a server by causing buffer overruns This restriction combats this threat. The default value is 256
If very long file or directory names on the server are used then this limit may need to be raised. The shorter the limit, the better the security.
Maximum number of commands per second
To prevent automated attacks against FTP server, restricting the frequency of commands can be useful. The default limit is 20 commands per second.
Allow 8-bit strings in control channel
The option determines if 8-bit characters are allowed in the control channel. Allowing 8-bit characters enables support for filenames containing international characters. For example, accented or umlauted characters.
Filetype Checking of FTP Transfers
To configure filetype checking with an IP Policy, a File Control Profile must be defined and then associated with the IP policy that allows the FTP transfer. This is described further in Section 6.5, File Control.Anti-Virus Scanning of FTP Transfers
The cOS Core anti-virus subsystem can be enabled to scan all FTP file downloads for malicious code. Suspect files can be dropped or just logged. With an IP policy, anti-virus scanning is enabled by associating an Anti-Virus Profile with the IP policy that allows the FTP transfer. This is described further in Section 6.4, Anti-Virus Scanning.Setting Up FTP Servers with Passive Mode
An important point about FTP server setup needs to be made if the FTP ALG is being used along with passive mode.Usually, the FTP server will be protected behind the Clavister firewall and cOS Core will SAT-Allow connections to it from external clients that are connecting across the Internet. If FTP Passive mode is allowed and a client connects with this mode then the FTP server must return an IP address and port to the client on which it can set up the data transfer connection.
This IP address is normally manually specified by the administrator in the FTP server software and the natural choice is to specify the external IP address of the interface on the firewall that connects to the Internet. This is, however, wrong if the FTP ALG is being used.
Instead, the local, internal IP address of the FTP server should be specified when setting up the FTP server.
ZoneDefense is a feature that allows cOS Core to block hosts and networks by sending management commands to certain types of external network switches. Used together with the FTP ALG, ZoneDefense can be configured to protect a network from the spread of malware such as viruses. This is relevant in two scenarios:A. Infected clients that need to be blocked.
B. Infected servers that need to be blocked.
These two scenarios will now be discussed in detail.
A. Blocking Infected Clients
The administrator configures the network range to include the local hosts of the network. If a local client tries to upload a virus infected file to an FTP server, cOS Core notices that the client belongs to the local network and will therefore upload blocking instructions to the local switches. The host will be blocked from accessing the local network and can no longer do any harm.
However, if a client downloads an infected file from a remote FTP server on the Internet, the server will not be blocked by ZoneDefense since it is outside of the configured network range. The virus is, however, still blocked by the firewall.
B. Blocking Infected Servers
Depending on the company policy, an administrator might want to take an infected FTP server off-line to prevent local hosts and servers from being infected. In this scenario, the administrator configures the address of the server to be within the range of the network to block. When a client downloads an infected file, the server is isolated from the network.
The steps for setting up ZoneDefense with the FTP ALG are the following:
Configure the ZoneDefense switches to be used with ZoneDefense in the ZoneDefense section of the Web Interface.
Set up the FTP ALG to use Anti-Virus scanning in enabled mode.
Choose the ZoneDefense network in the Anti-Virus configuration of the ALG that is to be affected by ZoneDefense when a virus is detected.
For more information about this topic refer to Section 7.11, ZoneDefense.
Methods of Setting Up the FTP ALG
Deploying the FTP ALG can be done using one of the following methods:Using IP Policies
Using an IP Policy object is the recommended setup method. It is easiest and provides additional options that are not available with IP rules. The FTP ALG options are configured directly by setting properties of the IP policy. Note that to configure FTP options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to FTP.
Using IP Rules
When using IP Rule objects, an FTP ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.
FTP ALG Setup Using IP Policies
Deploying the FTP ALG using IP policies requires the following steps:Create a new service object for FTP and set its Protocol property to be FTP. Alternatively, the predefined FTP service object called ftp could be used instead provided it has its Protocol property set to FTP.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make all the FTP ALG options available on the IP policy and these should be set appropriately.
Associate any other desired features with the IP policy. For example, associate a File Control Policy object for imposing file restrictions and/or a Anti-Virus Profile to perform anti-virus scanning on files.
The two examples that follow show how the FTP ALG is set up using IP policies for either FTP client or FTP server protection.
Example 6.6. FTP ALG Setup Using IP Policies to Protect an FTP Server
This example shows how to protect the server using the FTP ALG. An FTP Server on a DMZ is connected to a Clavister firewall and has a private IPv4 address, as illustrated below.
The FTP ALG restrictions will be the following:
Enable the FTP ALG option Allow active mode for client so FTP clients can use both active and passive modes.
Disable the FTP ALG option Allow passive mode for server. This is more secure for the FTP server as it will never receive passive mode data. The FTP ALG will handle all conversion if a client connects using passive mode.
Assume that the private IPv4 address of the FTP server is already defined in the address book with the name ftp-internal.
Command-Line Interface
A. Define a custom FTP service:
Device:/> add Service ServiceTCPUDP ftp-inbound-service
DestinationPorts=21
Type=TCP
Protocol=FTPB. Define a SAT policy translating connections to the public IP on port 21 to the server:
Device:/> add IPPolicy Name=sat-ftp-inbound
SourceInterface=any
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=ftp-inbound-service
Action=Allow
SourceAddressTranslation=None
DestinationAddressTranslation=SAT
DestinationAddressAction=SingleIP
DestNewIP=ftp-internal
FTPControl=Yes
FTPAllowServerPassive=Yes
FTPAllowClientActive=YesC. Traffic from the internal interface needs to be NATed through the public IPv4 address:
Device:/> add IPPolicy Name=nat-ftp
SourceInterface=dmz
SourceNetwork=dmz_net
DestinationInterface=core
DestinationNetwork=wan_ip
Service=ftp-inbound-service
Action=Allow
SourceAddressTranslation=NAT
NATSourceAddressAction=OutgoingInterfaceIP
FTPControl=Yes
FTPAllowServerPassive=Yes
FTPAllowClientActive=YesInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Define a custom FTP service:
B. Define a SAT policy translating connections to the public IP on port 21 to the server:
C. Traffic from the internal interface needs to be NATed through the public IPv4 address:
Example 6.7. FTP ALG Setup Using an IP Policy to Protect FTP Clients
This example shows how to protect FTP clients behind the firewall that are connecting to remote FTP servers on the Internet. The diagram below illustrates this scenario.
The FTP ALG will use the following options:
The FTP ALG option Allow active mode for client will be disabled so clients can only use passive mode. This is much safer for clients.
The FTP ALG option Allow passive mode for server will be enabled. This allows internal clients to connect to FTP servers that support active and passive mode across the Internet.
Command-Line Interface
A. Define the FTP Service:
Device:/> add Service ServiceTCPUDP ftp-outbound-service
DestinationPorts=21
Type=TCP
Protocol=FTPB. Create IP Policies:
IP rules need to be created to allow the FTP traffic to pass and these are different depending on if private or public IPv4 addresses are being used.
i. Using Public IPs:
If using public IPs throughout, make sure there are no rule set entries disallowing or allowing the same kind of ports/traffic placed before this entry
Device:/> add IPPolicy Name=allow-ftp-outbound
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=ftp-outbound-service
Action=Allow
SourceAddressTranslation=None
FTPControl=Yes
FTPAllowServerPassive=Yes
FTPAllowClientActive=Noii. Using Private IPs:
If the firewall is using private IPs for protected clients and a single external public IP for the Internet connection, the following NAT IP policy needs to be added instead of the previous policy in i above:
Device:/> add IPPolicy Name=nat-ftp-outbound
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=ftp-outbound-service
Action=Allow
SourceAddressTranslation=NAT
NATSourceAddressAction=OutgoingInterfaceIP
FTPControl=Yes
FTPAllowServerPassive=Yes
FTPAllowClientActive=NoInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Define the FTP Service:
B. Create IP Policies:
IP rules need to be created to allow the FTP traffic to pass and these are different depending on if private or public IPv4 addresses are being used.
i. Using Public IPs:
If using public IPs throughout, make sure there are no rule set entries disallowing or allowing the same kind of ports/traffic placed before this entry.
ii. Using Private IPs:
If the firewall is using private IPs for protected clients and a single external public IP for the Internet connection, the following NAT IP policy needs to be added instead of the previous policy in i above:
FTP ALG Setup Using IP Rules
An alternative to using IP policies for FTP ALG setup is to use IP rules. This requires the following steps:Create a new FTP ALG object with the desired options configured.
Create a new custom Service object for FTP and set its ALG property to the object created in the previous step.
Create an IP Rule object that uses the Service from the previous step. Multiple rules will be needed for SAT address translation.
The two examples that follow show how the FTP ALG is set up using IP rules for either FTP client or FTP server protection and replicate the scenarios of the previous examples that used IP policies.
Example 6.8. FTP ALG Setup Using IP Rules to Protect an FTP Server
This example repeats Example 6.6, “FTP ALG Setup Using IP Policies to Protect an FTP Server” but uses an IP Rule instead of an IP Policy.
Command-Line Interface
A. Define the ALG:
Device:/> add ALG ALG_FTP ftp-inbound
AllowClientActive=Yes
AllowServerPassive=Yes
B. Define the Service:
Device:/> add Service ServiceTCPUDP ftp-inbound-service
DestinationPorts=21
Type=TCP
ALG=ftp-inbound
C. Define a SAT rule allowing connections to the public IP on port 21 and forwarded to the FTP server:
Device:/> add IPRule Action=SAT
SourceInterface=any
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=ftp-inbound-service
SATTranslate=DestinationIP
SATTranslateToIP=ftp-internal
Name=SAT-ftp-inbound
D. Traffic from an internal interface needs to be NATed through the public IPv4 address:
Device:/> add IPRule Action=NAT
SourceInterface=dmz
SourceNetwork=dmz_net
DestinationInterface=core
DestinationNetwork=wan_ip
Service=ftp-inbound-service
NATAction=UseInterfaceAddress
Name=NAT-ftp
E. Allow incoming connections (SAT requires an associated Allow rule):
Device:/> add IPRule Action=Allow
SourceInterface=any
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=ftp-inbound-service
Name=Allow-ftp
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Define the ALG:
B. Define the Service:
C. Define a SAT rule allowing connections to the public IP on port 21 and forwarded to the FTP server:
D. Traffic from an internal interface needs to be NATed through the public IPv4 address:
E. Allow incoming connections (SAT requires an associated Allow rule):
Example 6.9. FTP ALG Setup Using IP Rules to Protect FTP Clients
This example repeats Example 6.6, “FTP ALG Setup Using IP Policies to Protect an FTP Server” but uses an IP Rule instead of an IP Policy.
Command-Line Interface
A. Define the ALG:
Device:/> add ALG ALG_FTP ftp-outbound
AllowClientActive=No
AllowServerPassive=Yes
B. Define the FTP Service:
Device:/> add Service ServiceTCPUDP ftp-outbound-service
DestinationPorts=21
Type=TCP
ALG=ftp-outbound
C. Create IP Rules:
IP rules need to be created to allow the FTP traffic to pass and these are different depending on if private or public IPv4 addresses are being used.
i. Using Public IPs:
If using public IPs, make sure there are no rules disallowing or allowing the same kind of ports/traffic placed before this rule.
Device:/> add IPRule Action=Allow
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=ftp-outbound-service
Name=Allow-ftp-outbound
ii. Using Private IPs:
If the firewall is using private IPs with a single external public IP, the following NAT rule needs to be added instead of the rule above:
Device:/> add IPRule Action=NAT
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=ftp-outbound-service
NATAction=UseInterfaceAddress
Name=NAT-ftp-outbound
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create the FTP ALG:
B. Create the Service:
C. Create IP Rules:
IP rules need to be created to allow the FTP traffic to pass and these are different depending on if private or public IPv4 addresses are being used.
i. Using Public IPs:
If using public IPs, make sure there are no rules disallowing or allowing the same kind of ports/traffic placed before this rule.
ii. Using Private IPs:
If the firewall is using private IPs with a single external public IP, the following NAT rule needs to be added instead of the rule above:
Overview
Trivial File Transfer Protocol (TFTP) is a much simpler version of FTP with more limited capabilities. Its purpose is to allow a client to upload files to or download files from a host system. TFTP data transport is based on the UDP protocol and therefore it supplies its own transport and session control protocols which are layered onto UDP.TFTP is widely used in enterprise environments for updating software and backing up configurations on network devices. TFTP is recognized as being an inherently insecure protocol and its usage is often confined to internal networks. The cOS Core ALG provides an extra layer of security to TFTP in being able to put restrictions on its use.
Methods of Setting Up the TFTP ALG
Deploying the TFTP ALG can be done using one of the following methods:Using IP Policies
Using an IP Policy object is the recommended setup method. It is easiest and provides additional options that are not available with IP rules. The TFTP ALG options are configured directly by setting properties of the IP policy. Note that to configure TFTP options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to TFTP.
Using IP Rules
When using IP Rule objects, a TFTP ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy. It will not be discussed further in this section.
TFTP ALG Setup Using an IP Policy
This section will discuss setting up the TFTP ALG using an IP Policy object. This is done with the following steps:Create a new service object which is a copy of the predefined tftp service and set its Protocol property to TFTP. Alternatively, set the Protocol property of the predefined service called tftp to the value TFTP and use that.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make the TFTP options available on the IP policy.
Make any adjustments to how the TFTP ALG behaves by changing the relevant properties of the IP Policy. The available options are discussed next.
TFTP ALG Options
The following options can be set on an IP Policy object once the Service for the TFTP protocol is associated with it:Use custom TFTP settings
Set this to ON to activate the TFTP ALG.
Allow read/write
The ALG can be set up to allow both read and write operations or just read or just write.
Remove options
Specifies if options should be removed from requests. The default is do not remove.
Allow unknown options
If this option is not enabled then any option in a request other than the blocksize, the timeout period and the file transfer size is blocked. The setting is disabled by default.
Specific TFTP Request Options
As long as the Remove Options property is set to false (options are not removed) then the following request option settings can also be set:Max blocksize
The maximum blocksize allowed can be specified. The allowed range is 0 to 65,464 bytes. The default value is 65,464 bytes.
Max file transfer size
The maximum size of a file transfer can be restricted. By default this is the maximum possible allowed which is 999,999 Kbytes.
Block directory traversal
This option can disallow directory traversal through the use of filenames containing consecutive periods ("..").
Request Repetition
The cOS Core TFTP ALG blocks the repetition of a TFTP request coming from the same source IP address and port within a fixed period of time. The reason for this is that some TFTP clients might issue requests from the same source port without allowing an appropriate timeout period the reply.Example 6.10. TFTP ALG Setup Using an IP Policy
In this example, read-only TFTP connections are allowed from the Internet to a web server located in a DMZ. The Clavister firewall is connected to the Internet via the wan interface with address object wan_ip as its IP address. The web server has the private IPv4 address 198.168.0.1 and so connections arriving at the wan interface will be subject to SAT translation.
The predefined cOS Core service called tftp will be used but it will need to have its Protocol property set first.
Command-Line Interface
Set the Protocol property of the tftp service
:Device:/> set Service ServiceTCPUDP tftp Protocol=TFTPCreate a SAT IP Policy for TFTP:
Device:/> add IPPolicy Name=SAT_TFTP_To_DMZ
SourceInterface=wan
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=tftp
Action=Allow
SourceAddressTranslation=None
DestinationAddressTranslation=SAT
DestinationAddressAction=SingleIP
DestNewIP=192.168.0.1
TFTControl=Yes
TFTPAllowedCommands=ReadInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Set the Protocol property of the tftp service
:Create a SAT IP policy for TFTP:
Overview
Simple Mail Transfer Protocol (SMTP) is a text based protocol used for transferring email between mail servers over the Internet. Typically, a local mail server will be located on a DMZ so that mail sent by remote mail servers will traverse the Clavister firewall to reach the local server.Local clients behind the firewall will then use email client software to retrieve email from the server and to send mail to the server for forwarding out to other mail servers on the Internet. Various protocols may be used for communication between clients and a mail server. Microsoft ActiveSync™ is a common choice. Retrieval may also be done with the POP3 or IMAP protocol but sending mail to the server may be done using SMTP. These interactions are illustrated in the diagram below.
The SMTP ALG can be used to process both SMTP traffic between mail servers as well as from clients to servers. A typical mail sending sequence would be the following:
A local user sends an email to a mail server. This might be sent using SMTP or Microsoft Activesync™ or some other protocol.
The local mail server performs a DNS lookup of the destination domain name to determine the IP address of the remote mail server to forward the mail to.
The email is forwarded to the remote server using SMTP.
The remote user retrieves the email from the remote mail server using POP3 or IMAP or Activesync or some other protocol.
The most common use for the SMTP ALG is to examine the email traffic that is flowing to a mail server from the Internet and setting this up is described in the example given later. However, it is possible for malware to infect either protected clients and/or a mail server in which case an SMTP ALG can be used to monitor mail traffic that is flowing from clients and/or being relayed by the mail server out on the Internet.
Methods of Setting Up the SMTP ALG
Deploying the SMTP ALG can be done using one of the following methods:Using IP Policies
Using an IP Policy object is the recommended setup method. It is easiest and provides additional options that are not available with IP rules. Note that to configure SMTP options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to SMTP.
Using IP Rules
When using IP Rule objects, an SMTP ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.
SMTP ALG Setup Using an IP Policy
Setting up the SMTP ALG with an IP policy is done with the following steps:Create a new service object with the following settings:
Type: TCP
Destination: 25
Enable Syn Flood Protection for traffic from the Internet. Having this disabled will use less cOS Core resources but disable it only where a denial-of-service attack is unlikely (discussed further in Other Service Properties).
Set the Protocol property to SMTP.
Alternatively, set the Protocol property of the predefined service called smtp to the value SMTP and use that.
Note that the predefined service smtp-in is identical to smtp except it has the SYN flood protection option enabled.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make all SMTP ALG options available on the IP policy.
The selection of source and destination filters for the IP policy could be one of the following options:
For mail being uploaded to the server from clients using SMTP, the source will be the clients and the destination will be the mail server.
For mail being sent to the server from the Internet, the destination is the mail server and the source is the Internet. If the mail server does not have its own public IP address, this will require SAT address translation to translate the public IP address to the private address of the server.
For mail from clients being forwarded out to the Internet by the mail server, the server is the source and the Internet is the destination.
Create and configure a new Email Control Profile and assign it to the IP policy.
Optionally also assign a newly created File Control Profile and/or a Anti-Virus Profile to apply those features to the SMTP traffic. Application control can also be configured on the IP policy.
SMTP ALG Options
When using an IP policy, the SMTP ALG is enabled by associating an Email Control Profile object with the policy. The following options are configurable on the Email Control Profile for SMTP:SPAM Filtering
Emails can be filtered for SPAM. This is described further in Section 6.3.1, Email Control Profiles with IP Policies.
Max Email Rate
A maximum allowable rate of email messages can be specified. This rate is calculated on a per source IP address basis. In other words, it is not the total rate that is of interest but the rate from a certain email source.
This is a very useful feature to have since it is possible to put in a block against either an infected client or an infected server sending large amounts of malware generated emails.
Max Email Size
A maximum allowable size of email messages can be specified. This feature counts the total amount of bytes sent for a single email which is the header size plus body size plus the size of any email attachments after they are encoded. It should be kept in mind that an email with, for example, an attachment of 100 Kbytes will actually be larger than 100 Kbytes. The transferred size might be 120 Kbytes or more since the encoding which takes place automatically for attachments may substantially increase the transferred attachment size.
The administrator should therefore add a reasonable margin above the anticipated email size when setting this limit.
By default, encrypted SMTP traffic is always dropped by the ALG. If this property is enabled, encrypted traffic will not be dropped if the STARTTLS command has been used to change over from plain text. However, none of the ALG's functions will be applied to this encrypted traffic.
Email Address WhiteListing/Blacklisting
Specific email addresses can be whitelisted or blacklisted so that mail from/to those addresses is either always allowed or blocked. The blacklist is applied after the whitelist so that if an address matches a whitelist entry it is not then checked against the blacklist. Wildcards can be used when specifying email addresses.
Other Options
The following options can also be configured on an IP policy that triggers on SMTP traffic:File Control
A File Control Profile can be associated with an IP policy to place checks on files transferred.
With IP rules, this option is configured on the SMTP ALG object used.
An Anti Virus Profile can be associated with an IP policy to scan transferred files for viruses.
With IP rules, this option is configured on the SMTP ALG object.
Application Control
Application control can be applied to SMTP traffic. This is described further in Section 3.7, Application Control.
This option is not available with IP rules.
The Ordering for SMTP ALG Processing
SMTP filtering obeys the following processing order and is similar to the order followed by the HTTP ALG except for the addition of Spam filtering:As described above, if an address is found on the whitelist then it will not be blocked if it also found on the blacklist. Spam filtering, if it is enabled, is still applied to whitelisted addresses but emails flagged as spam will not be tagged or dropped, only logged. Anti-virus scanning, if it is enabled, is always applied, even though an email's address is whitelisted.
Notice that either an email's sender or receiver address can be the basis for blocking by one of the first two filtering stages.
Using Wildcards in White and Blacklists
Entries made in the white and blacklists can make use of wildcarding to have a single list entry cover a large number of potential email addresses. The wildcard character "*" is used to represent any sequence of characters of any length.For instance, the list entry *@example.com can be used to specify all possible email addresses related to the domain example.com.
To explicitly allow emails destined for my_department, add the whitelist entry my_department@example.com and this will have precedence over the blacklist entry with the wildcard.
Enhanced SMTP and Extensions
Enhanced SMTP (ESMTP) is defined in RFC-1869 and allows a number of extensions to the standard SMTP protocol.When an SMTP client opens a session with an SMTP server using ESMTP, the client first sends an EHLO command. If the server supports ESMTP it will respond with a list of the extensions that it supports. These extensions are defined by various separate RFCs. For example, RFC-2920 defines the SMTP Pipelining extension. Another common extension is Chunking which is defined in RFC-3030.
The cOS Core SMTP ALG does not support all ESMTP extensions including Pipelining and Chunking. The ALG therefore removes any unsupported extensions from the supported extension list that is returned to the client by an SMTP server behind the firewall. When an extension is removed, a log message is generated with the text:
unsupported_extension capability_removed
The parameter "capa=" in the log message indicates which extension the ALG removed from the server response. For example, this parameter may appear in the log message as:
capa=PIPELINING
To indicate that the pipelining extension was removed from the SMTP server reply to an EHLO client command.
Although ESMTP extensions may be removed by the ALG and related log messages generated, this does not mean that any emails are dropped. Email transfers will take place as usual but without making use of unsupported extensions removed by the ALG.
Example 6.11. SMTP ALG Setup Using an IP Policy
In this example, an SMTP ALG is to be used to monitor email traffic that is flowing to a mail server on a DMZ network from the Internet. It is assumed that the mail server has a private IPv4 address which is defined by the address book object mail_server_ip so a SAT IP rule will be needed to translate the firewall's public IP address to this private address. The scenario is illustrated in the diagram below.
It is also assumed that the wan interface of the firewall is connected to the Internet and the public IP address of the interface is defined by the wan_ip address book object.
The SMTP ALG will be set up to perform the following actions:
Command-Line Interface
A. Create a new Service object for inbound SMTP traffic:
Device:/> add Service ServiceTCPUDP smtp_inbound_service
Type=TCP
DestinationPorts=25
SYNRelay=Yes
Protocol=SMTPB. Create an EmailControlProfile object:
Device:/> add Policy EmailControlProfile my_ec_profile
AntiSpam=Yes
DNSBL=Yes
DNSBL1=Yes
DNSBL1Name=b.barracudacentral.org
DNSBL1Score=5
DNSBL2=Yes
DNSBL2=dnsbl1.droneb1.org
DNSBL2Score=3Device:/>cc Policy EmailControlProfile my_ec_profileDevice:/my_ec_profile>add EmailFilter SrcEmail=*@example.com SrcType=Email Action=BlacklistDevice:/my_ec_profile>ccDevice:/>
C. Create an AntiVirusPolicy object:
Device:/> add Policy AntiVirusPolicy my_av_policyD. Create a FileControlPolicy object:
Device:/> add Policy FileControlPolicy my_fc_policy
FileListType=Block
File=exe,msi
VerifyContentMimeType=YesE. Create an IP Policy for email traffic from the Internet:
Device:/> add IPPolicy Name=smtp_inbound_sat
SourceInterface=wan
SourceNetwork=all_nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=smtp_inbound_service
Action=Allow
SourceAddressTranslation=None
DestinationAddressTranslation=SAT
DestinationAddressAction=SingleIP
DestNewIP=mail_server_ip
EmailControl=Yes
EC_Policy=my_ec_profile
AntiVirus=Yes
AV_Mode=UsePolicy
AV_Policy=my_av_policy
FileControl=Yes
FC_Mode=UsePolicy
FC_Policy=my_fc_policyInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a new Service object for inbound SMTP:
B. Create an Email Control Profile object:
C. Create an Anti-Virus Profile object:
D. Create a File Control Profile object:
E. Create an IP Policy for email traffic to the mail server from the Internet:
SMTP ALG Setup with IP Rules
To set up security using the SMTP ALG, perform the following steps:Create a new SMTP ALG object with the desired options enabled, such as file blocking and virus scanning.
Create a new custom Service object for SMTP with the following properties:
Type: TCP
Destination: 25
Enable Syn Flood Protection if traffic is coming from the Internet.
ALG: Assign the service from the previous step.
Create an IP Rule object that that uses the Service from the previous step. Multiple rules will be needed for SAT address translation.
Example 6.12. SMTP ALG Setup with IP Rules
This example repeats Example 6.11, “SMTP ALG Setup Using an IP Policy” but uses IP rules instead of a single IP policy.
Command-Line Interface
A. Create an SMTP ALG object:
Device:/> add ALG ALG_SMTP smtp_inbound_alg
FileListType=Block
File=exe,msi
VerifyContentMimetype=Yes
Antivirus=Protect
DNSBL=Yes
DNSBlackLists={b.barracudacentral.org;5},{dnsbl.dronebl.org;3}
Also in this ALG, blacklist all mails sent from the example.com domain:
Device:/>cc ALG ALG_SMTP smtp_inbound_algDevice:/smtp_inbound_alg>add ALG_SMTP_Email Action=Blacklist Type=Sender Email=*@example.comDevice:/smtp_inbound_alg>ccDevice:/>
B. Create a new Service object for inbound SMTP traffic:
Device:/> add Service ServiceTCPUDP smtp_inbound_service
Type=TCP
DestinationPorts=25
SYNRelay=Yes
ALG=smtp_inbound_alg
C. Create an IP Rule for email traffic from the Internet:
i. Create a SAT IP rule to translate the server address:
Device:/> add IPRule Action=SAT
SourceInterface=wan
SourceNetwork=all_nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=smtp_inbound_service
SATTranslate=DestinationIP
SATTranslateToIP=mail_server_ip
Name=smtp_inbound_sat
ii. Create a matching ALLOW IP rule to permit the translated traffic:
Device:/> add IPRule Action=Allow
SourceInterface=wan
SourceNetwork=all_nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=smtp_inbound_service
Name=smtp_inbound_allow
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create an SMTP ALG object:
B. Create a new Service object for inbound SMTP:
C. Create an IP Rule for email traffic to the mail server from the Internet:
i. Create a SAT IP rule to translate the server address:
ii. Create a matching ALLOW IP rule to permit the translated traffic:
ZoneDefense is a feature that allows cOS Core to block hosts and networks by sending management commands to certain types of external network switches. SMTP is used for both mail clients that want to send emails as well as mail servers that relay emails to other mail servers. When using ZoneDefense together with the SMTP ALG, the only scenario of interest is to block local clients that try to spread viruses in outgoing emails.
Using ZoneDefense for blocking relayed emails to an incoming SMTP server would be inadvisable since it would disallow all incoming emails from the blocked email server. For example, if a remote user is sending an infected email using a well-known free email company, blocking the sending server using ZoneDefense would block all future emails from that same company to any local receiver. Using ZoneDefense together with the SMTP ALG should therefore be used principally for blocking local email clients.
To implement blocking, the administrator configures the ZoneDefense network range to include all local SMTP clients. The SMTP-server itself should be excluded from this range.
![[Tip]](images/tip.png) |
Tip: Exclusion can be manually configured |
|---|---|
|
It is possible to manually configure certain hosts and servers to be excluded from being blocked by adding them to the ZoneDefense Exclude List. |
When a client tries to send an email infected with a virus, the virus is blocked and ZoneDefense isolates the host from the rest of the network.
Setup Steps
The steps to setting up ZoneDefense with the SMTP ALG are:Configure the ZoneDefense switches to be used with ZoneDefense by going to the ZoneDefense section of the Web Interface.
Set up the SMTP ALG to use Anti-Virus scanning in enabled mode. With an IP policy this done by defining an Anti-Virus policy object and associating it with the policy.
Choose the ZoneDefense network in the Anti-Virus configuration that is to be affected by ZoneDefense when a virus is detected.
More information about this topic can be found in Section 7.11, ZoneDefense.
POP3 is a mail transfer protocol that is used by a recipient's email client to download emails from a mail server. The principal difference with the IMAP protocol is that the entire email and any attachments are downloaded to the client before the email can be examined. The email is then subsequently stored on the client computer and may be deleted from the mail server.
The diagram below illustrates a typical usage of the cOS Core POP3 ALG. A mail server located on the DMZ network dmz_net receives emails from the Internet using the SMTP protocol. A protected client on the lan_net network downloads emails from this server using the POP3 protocol. The clients initiate the transfer with POP3, sending a request to the mail server for the download of emails also using POP3.
As the emails traverse the firewall, the cOS Core POP3 ALG examines the data and can block or allow them according to the behavior specified in the ALG configuration object.
In this scenario, the SMTP traffic arriving at the mail server on the DMZ also traverses the firewall and this traffic can be examined using the cOS Core SMTP ALG. This is discussed further in Section 6.1.5, SMTP ALG.
Methods of Setting Up the POP3 ALG
Deploying the POP3 ALG can be done using one of the following methods:Using IP Policies
Using an IP Policy object is the recommended setup method. It is easiest and provides additional options that are not available with IP rules. Note that to configure POP3 options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to POP3.
Using IP Rules
When using IP Rule objects, a POP3 ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.
POP3 ALG Setup Using an IP Policy
Setting up the POP3 ALG with an IP policy is done with the following steps:Create a new service object which is a copy of the predefined pop3 service and set its Protocol property to POP3. Alternatively, set the Protocol property of the predefined service called pop3 to the value POP3 and use that.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make all the POP3 ALG options available on the IP policy.
Create and configure a new Email Control Profile and assign it to the IP policy.
Optionally also assign a newly created File Control Profile and/or a Anti-Virus Profile to apply those features to the POP3 traffic. Application control can also be configured on the IP policy.
POP3 ALG Options
When using an IP policy, the POP3 ALG is enabled by associating an Email Control Profile object with the policy. The following options are configurable on the Email Control Profile for POP3:SPAM Filtering
Emails can be filtered for SPAM. This is described further in Section 6.3.1, Email Control Profiles with IP Policies.
Anti-Spam scanning by the POP3 ALG can be redundant if scanning is already performed on mail traffic before it reaches the mail server. This scanning could be done by the cOS Core SMTP ALG.
Hide User
This option prevents the POP3 server from revealing that a username does not exist. This prevents users from trying different usernames until they find a valid one. For an IP policy, this is found in the Email Control Profile and is disabled by default.
Allow Unknown Commands
Non-standard POP3 commands not recognized by the ALG can be allowed or disallowed. With an IP policy, this is found in the Email Control Profile and is disabled by default.
Block USER/PASS Commands
Block connections between client and server that send the username/password combination as clear text which can be easily read (some servers may not support other methods than this). With an IP policy, this is found in the Email Control Profile and is disabled by default.
By default, encrypted POP3 traffic is always dropped by the ALG. If this property is enabled, encrypted traffic will not be dropped if the STARTTLS command has been used to change over from plain text. However, none of the ALG's functions will be applied to this encrypted traffic.
Other Options
The following options can also be configured on an IP policy that triggers on POP3 traffic:File Control
A File Control Profile can be associated with an IP policy to place checks on files transferred.
With IP rules, this option is configured on the POP3 ALG object used.
An Anti Virus Profile can be associated with an IP policy to scan transferred files for viruses.
With IP rules, this option is configured on the POP3 ALG object.
Application Control
Application control can be applied to POP3 traffic. This is described further in Section 3.7, Application Control.
This option is not available with IP rules.
Example 6.13. POP3 ALG Setup Using an IP Policy
This example will assume the network topology illustrated in the diagram at the beginning of this section. POP3 traffic is to be allowed between a mail server on the dmz_net network and protected clients on the lan_net network. It is assumed that the mail server has a private IPv4 address which is defined by the address book object mail_server_ip.
The POP3 ALG will perform the following actions:
Note that clients will initiate POP3 connections so they will be the source network for the IP policy.
Command-Line Interface
A. Create a new Service object for POP3:
Device:/> add Service ServiceTCPUDP pop3_client_service
Type=TCP
DestinationPorts=110
Protocol=POP3B. Create an EmailControlProfile object:
Device:/> add Policy EmailControlProfile my_ec_profile HideUser=YesC. Create an AntiVirusPolicy object:
Device:/> add Policy AntiVirusPolicy my_av_policyD. Create an FileControlPolicy object:
Device:/> add Policy FileControlPolicy my_fc_policy
FileListType=Block
File=exe,msi
VerifyContentMimeType=YesE. Create an IP Policy for email traffic from the mail server:
Device:/> add IPPolicy Name=pop3_policy
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=dmz
DestinationNetwork=mail_server_ip
Service=pop3_client_service
Action=Allow
SourceAddressTranslation=None
EmailControl=Yes
EC_Policy=my_ec_profile
AntiVirus=Yes
AV_Mode=UsePolicy
AV_Policy=my_av_policy
FileControl=Yes
FC_Mode=UsePolicy
FC_Policy=my_fc_policy
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a new Service object for POP3:
B. Create an Email Control Profile object:
C. Create an Anti-Virus Profile object:
D. Create an File Control Profile object:
E. Create an IP Policy for email traffic from the mail server:
POP3 ALG Setup Using IP Rules
Setting up the POP3 ALG with an IP Rule requires the following steps:Create a new POP3 ALG object with the desired options enabled, such as file blocking and virus scanning. There is no predefined POP3 ALG in cOS Core.
Create a new custom Service object for POP3 with the following properties:
This is now a copy of the predefined Service object called pop3. This predefined object could be used instead.
Associate the new POP3 ALG object with the newly created Service object.
Create an IP Rule object that has the mail server as its Destination Network and the email clients as its Source Network since it is the clients which will initiate connections.
Associate the Service object with the IP rule.
Example 6.14. POP3 ALG Setup Using IP Rules
This example will repeat the scenario found in Example 6.13, “POP3 ALG Setup Using an IP Policy” but will use an IP Rule instead if an IP Policy.
Command-Line Interface
A. Create a POP3 ALG object:
Device:/> add ALG ALG_POP3 pop3_client_alg
HideUser=Yes
FileListType=Block
File=exe,msi
VerifyContentMimetype=Yes
Antivirus=Protect
B. Create a new Service object for POP3:
Device:/> add Service ServiceTCPUDP pop3_client_service
Type=TCP
DestinationPorts=110
ALG=pop3_client_alg
C. Create an IP Rule for email traffic from the mail server:
Device:/> add IPRule Action=Allow
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=dmz
DestinationNetwork=mail_server_ip
Service=pop3_client_service
Name=pop3_mail
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a POP3 ALG object:
B. Create a new Service object for POP3:
C. Create an IP Rule for email traffic from the mail server:
Note that clients initiate the POP3 connection so they are the source for the IP rule.
IMAP is a mail transfer protocol that is used by a recipient's email client to download emails from a mail server. The principal difference with the POP3 protocol is that the entire email and any attachments are not downloaded to the client along with the email header. Instead, only the mail header is downloaded and the user can then choose to read the body in which case the entire email with any attachments will be downloaded. Alternatively, a mail could be deleted on the server without the rest of the email ever being downloaded to the client.
Setting Up the IMAP ALG
Deploying the IMAP ALG can only be done using an IP policy and requires the following steps:Create a new service object which is a copy of the predefined imap service and set its Protocol property to IMAP. Alternatively, set the Protocol property of the predefined service called imap to the value IMAP and use that.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make all the IMAP ALG options available on the IP policy.
Create and configure a new Email Control Profile and assign it to the IP policy.
Optionally also assign a newly created File Control Profile and/or a Anti-Virus Profile to apply those features to the IMAP traffic. Application control can also be configured on the IP policy.
IMAP ALG Options
When using an IP policy, the IMAP ALG is enabled by associating an Email Control Profile object with the policy. The following options are configurable on the Email Control Profile for IMAP:SPAM Filtering
Emails can be filtered for SPAM. This is described further in Section 6.3.1, Email Control Profiles with IP Policies and that section also includes details about how cOS Core SPAM filtering differs for the IMAP protocol.
Anti-Spam scanning by the IMAP ALG can be redundant if scanning is already performed on mail traffic before it reaches the mail server. This scanning could be done by the cOS Core SMTP ALG.
Hide User
If the wrong credentials are sent to this server, enabling this option prevents the server's error message being returned to the client. Some servers might send an error message which gives an indication which of the credentials is incorrect and this could be helpful in a security attack. Instead, cOS Core will send back its own general error message to the client.
By default, this option is disabled.
Block Plain Text Authentication
When enabled, authentication using credentials sent in plain text will be blocked.
Allow STARTTLS
This allows STARTTLS commands in the IMAP negotiation. By default, this is disabled.
Other Options
The following options can also be configured on an IP policy that triggers on IMAP traffic:File Control
A File Control Profile can be associated with an IP policy to place checks on files transferred.
An Anti Virus Profile can be associated with an IP policy to scan transferred files for viruses.
Application Control
Application control can be applied to IMAP traffic. This is described further in Section 3.7, Application Control.
Example 6.15. IMAP ALG Setup
This example shows how to set up an IP Policy object which allows internal clients on lan_net to retrieve email from a mail server located on dmz_net using the IMAP protocol. This retrieval is illustrated below.
The additional requirements are as follows:
Command-Line Interface
A. Create an EmailControlProfile object for filtering the mail:
Device:/> add Policy EmailControlProfile my_email_profile
AntiSpam=Yes
SubjectTag="*** Probably SPAM ***"
DomainVerificationScore=5
LinkProtectionScore=5
DNSBL=Yes
DNSBL1=Yes
DNSBL1Name=b.barracudacentral.orgB. Add an EmailFilter object to the profile for whitelisting:
Change the CLI context to be the profile:
Device:/> cc EmailProfile my_email_profileAdd an EmailFilter object as a child:
Device:/my_email_profile> add EmailFilter
Action=Whitelist
SrcType=Email
SrcEmail=*@example.comReturn to the default CLI context:
Device:/main>ccDevice:/>
C. Create a custom Service for IMAP:
Command-Line Interface
Device:/> add Service ServiceTCPUDP my_imap_service
Type=TCP
DestinationPorts=143
Protocol=IMAPD. Add an IPPolicy to allow IMAP traffic and associate the profile with it:
Device:/> add IPPolicy Name=lan_to_dmz
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=dmz
DestinationNetwork=dmz_net
Service=my_imap_service
Action=Allow
SourceAddressTranslation=None
EmailControl=Yes
EC_Policy=my_email_profileInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create an Email Control Profile object for filtering the mail:
B. Add an EmailFilter object to the profile for whitelisting:
C. Create a custom Service for IMAP:
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
D. Add an IP Policy to allow IMAP traffic and associate the profile with it:
The PPTP ALG is provided to deal with a specific issue when PPTP tunnels are used with NAT.
Suppose there are two clients A and B on a protected inner network behind a Clavister firewall. The firewall is connected to the external Internet and a NAT IP policy is defined to allow traffic from the clients to flow to the Internet. Both clients will therefore appear to have from the same IP address as they make connections to servers across the Internet.
One client A now establishes a PPTP tunnel to an external host C across the Internet. The tunnel endpoints are the client and the external server. Because of the NAT IP rule, the tunnel connection will appear to be coming from the external IP address on the firewall.
This first connection will be successful but when the second client B also tries to connect to the same server C at the same endpoint IP address, the first connection for A will be lost. The reason is that both clients are trying to establish a PPTP tunnel from the same external IP address to the same endpoint.
The PPTP ALG solves this problem. By using the ALG, the traffic from all the clients can be multiplexed through a single PPTP tunnel between the firewall and the server.
Methods of Setting Up the PPTP ALG
Deploying the PPTP ALG can be done using one of the following methods:Using IP Policies
Using an IP Policy object is the recommended setup method. Note that to configure PPTP options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to TLS.
Using IP Rules
When using IP Rule objects, a PPTP ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.
PPTP ALG Setup Using an IP Policy
This section will discuss setting up the PPTP ALG using an IP Policy object. This is done with the following steps:Create a new custom TCP/UDP service object with the following properties:
Alternatively, set the Protocol property of the predefined service called pptp-ctl to the value PPTP and use that.
Create a new IP Policy object that triggers on the targeted traffic and set its Service property to be the service object from the previous step. These will make the PPTP ALG options available on the IP policy.
Make any adjustments to how the PPTP ALG behaves by changing the relevant properties of the IP Policy. The available options are discussed next.
PPTP ALG Options
The following options can be set on an IP Policy object once the Service for the PPTP protocol is associated with it:Enable PPTP settings
Set this to ON to activate the PPTP ALG.
Echo timeout
Idle timeout period for echo messages inside the PPTP tunnel.
Idle timeout
Idle timeout for user traffic messages in the PPTP tunnel.
In most scenarios these settings can be left at their default values.
Example 6.16. PPTP ALG Setup Using an IP Policy
This example adds a NAT IP policy that will perform address translation for all PPTP traffic originating from the internal network lan flowing to the Internet on the wan interface. The IP address of the wan interface will be used as the NATing address for all connections.
The PPTP ALG will be applied to the traffic and the default PPTP ALG settings will be used. The clients on lan_net are the local endpoint of the PPTP tunnels. The table below summarizes the setup.
| Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|
| Allow/NAT | lan | lan_net | wan | all-nets | pptp_ctl |
Command-Line Interface
Device:/> add IPPolicy Name=nat_pptp
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=pptp-ctl
Action=Allow
SourceAddressTranslation=NAT
NATSourceAddressAction=OutgoingInterfaceIP
PPTPControl=Yes
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
PPTP ALG Setup Using an IP Rule
Although using an IP policy is the recommended method for deploying a PPTP ALG, an alternative but more complicated method is to use an IP Rule object instead. The sequence of steps for setup is as follows:Define a new PPTP ALG object with an appropriate name. There is no predefined PPTP ALG in the default cOS Core configuration.
Associate the ALG object with an appropriate Service object. The predefined service called pptp-ctl can be used for this purpose or a custom service can be created that is a copy of pptp-ctl.
Make any desired changes to the ALG's properties.
Associate this service object with the NAT IP rule that permits the traffic to flow from clients to the remote endpoint of the PPTP tunnel. This may be an IP rule that NATs the traffic out to the Internet with a destination network of all-nets.
Overview
Session Initiation Protocol (SIP) is an ASCII (UTF-8) text based signaling protocol used to establish sessions between clients in an IP network. It is a request-response protocol that resembles HTTP and SMTP. The session which SIP sets up might consist of a Voice-Over-IP (VoIP) telephone call or it could be a collaborative multi-media conference. Using SIP with VoIP means that telephony can become another IP application which can integrate into other services.SIP Sets Up Sessions
SIP does not know about the details of a session's content and is only responsible for initiating, terminating and modifying sessions. Sessions set up by SIP are typically used for the streaming of audio and video over the Internet using the RTP/RTCP protocol (which is based on UDP) but they might also involve traffic based on the TCP protocol. An RTP/RTCP based session might also involve TCP or TLS based traffic in the same session.The SIP RFC
SIP is defined by IETF RFC-3261 and this is considered an important general standard for VoIP communication. It is comparable to H.323, however, a design goal with SIP was to make SIP more scalable than H.323. (For VoIP, see also Section 6.1.10, H.323 ALG.)cOS Core Supports Three Scenarios
Before continuing to describe SIP in more depth, it is important to understand that cOS Core supports SIP usage in three distinct scenarios:Protecting Local Clients
In this scenario, the proxy is located somewhere on the Internet.
Protecting Proxy and Local Clients
Here, the proxy is located on the same network as the clients. However, this case can be divided into two scenarios:
Configuration Limitations with SIP
The following cOS Core configuration limitations exist for SIP traffic passing through the SIP ALG:SIP ALG traffic cannot be configured with any other routing table except the main routing table. This means the cOS Core Virtual Routing feature cannot be configured, nor can policy-based routing (PBR) rules be used with the SIP ALG.
The Route Failover feature cannot be used.
Traffic shaping cannot be applied to SIP ALG traffic.
SIP Components
The following components are the logical building blocks for SIP communication:These act as routers in the SIP protocol, performing both as client and server when receiving client requests. They forward requests to a client's current location as well as authenticating and authorizing access to services. They also implement provider call-routing policies.
The proxy is often located on the external, unprotected side of the firewall but can have other locations. All of these scenarios are supported by cOS Core.
A server that handles SIP REGISTER requests is given the special name of Registrar. The Registrar server has the task of locating the host from which the other client is reachable.
The Registrar and Proxy Server are logical entities and may, in fact, reside on the same physical server.
SIP Media-related Protocols
A SIP session makes use of a number of protocols. These are:Methods of Setting up the SIP ALG
Deploying the SIP ALG can be done using one of the following methods:Using a VoIP Profile with an IP Policy
The SIP ALG can be configured using IP Policy objects and this is the recommended method. Setup is done by creating a VoIP Profile object and specifying SIP options on that. The VoIP Profile object is then associated with an IP Policy object that triggers on the target traffic.
A Service object configured for SIP traffic must also be used with the IP Policy object. This Service object must have its Protocol property set to SIP.
The predefined SIP service objects in the default configuration for cOS Core 11.03 and later already have their Protocol property set to be SIP. This will not be true where cOS Core has been upgraded to version 11.03 or later.
Using a SIP ALG with an IP Rule
Alternatively, a SIP ALG object can be associated with a Service object configured for the SIP protocol. The service object is then used with the IP Rule objects that trigger on the SIP traffic flow.
In cOS Core version 11.03 and later, a predefined SIP ALG is not present in the default configuration and therefore a new SIP ALG object must always be created when using an IP Rule object with SIP. In older cOS Core versions that are upgraded to 11.03 or later, the predefined SIP ALG object will be retained.
SIP ALG Setup Using IP Policies
When configuring the SIP ALG using IP Policy objects, the following steps are required:Define a single Service object for SIP communication. The Protocol property must be set to SIP if the service is to be used with an IP Policy object.
Define a VoIP Profile object and disable H.323 but leave SIP enabled. Change the SIP settings as required.
Define an IP Policy object that allows the SIP traffic, setting the Service property to the object created in the first step.
Associate the VoIP Profile object created in the second step with the IP Policy object.
The Predefined SIP Service Could Be Used
The predefined Service object called sip-udp could be used as the service in the steps above. However, it is recommended to create a new, custom Service object and the examples given here do this.Note that any SIP service object used with IP policies must used have its Protocol property set to SIP and this may not already be the case with the predefined sip-udp object if there have been upgrades from much older cOS Core versions.
The following options can be configured for the SIP ALG object. For IP policies, this is done on the VoIP object created:Max Sessions per ID
The number of simultaneous sessions that a single client can be involved with is restricted by this value. The default value is 5.
Max Registration Time
The maximum time for registration with a SIP Registrar. The default value is 3600 seconds.
SIP Signal Timeout
The maximum time allowed for SIP sessions. The default value is 43200 seconds.
Data Channel Timeout
The maximum time allowed for periods with no traffic in a SIP session. A timeout condition occurs if this value is exceeded. The default value is 120 seconds.
Allow TCP Data Channels
TCP data channels can be used during a SIP session. This is enabled by default.
Max TCP Data Channels
If Allow TCP Data Channels is enabled this option is available to specify the maximum time number of TCP channels allowed in a SIP session. The default value is 10.
Allow Media Bypass
If this option is enabled then data, such as RTP/RTCP communication, may take place directly between two clients without involving the firewall. This would only happen if the two clients were behind the same interface and belong to the same network. This setting is enabled by default.
The SIP Proxy Record-Route Option
To understand how to set up SIP scenarios with cOS Core, it is important to first understand the SIP proxy Record-Route option. SIP proxies have the Record-Route option either enabled or disabled. When it is switched on, a proxy is known as a Stateful proxy. When Record-Route is enabled, a proxy is saying it will be the intermediary for all SIP signaling that takes place between two clients.When a SIP session is being set up, the calling client sends an INVITE message to its outbound SIP proxy server. The SIP proxy relays this message to the remote proxy server responsible for the called, remote client's contact information. The remote proxy then relays the INVITE message to the called client. Once the two clients have learnt of each other's IP addresses, they can communicate directly with each other and remaining SIP messages can bypass the proxies. This facilitates scaling since proxies are used only for the initial SIP message exchange.
The disadvantage of removing proxies from the session is that cOS Core IP rule set entries must be set up to allow all SIP messages through the firewall, and if the source network of the messages is not known then a large number of potentially dangerous connections must be allowed by the IP rule set. This problem does not occur if the local proxy is set up with the Record-Route option enabled. In this mode, all SIP messages will only come from the proxy.
The different entries required when the Record-Route option is
enabled and disabled can be seen in the two different sets of IP rule set entries
listed below in the detailed description of Scenario 1
Protecting local clients - Proxy located on the Internet.
IP Rule Set Entries for Media Data
When discussing SIP data flows there are two distinct types of exchanges involved:The SIP session which sets up communication between two clients prior to the exchange of media data.
The exchange of the media data itself, for example the coded voice data which constitute a VoIP phone call.
In the SIP setups described below, IP rule set entries need only be explicitly defined to deal with the first of the above, which is the SIP exchanges needed for establishing client-to-client communications. No IP rule set entries or other objects need to be defined to handle the second of the above (the exchange of media data). The SIP ALG automatically takes care of creating the connections required (sometimes described as SIP pinholes) for allowing the media data traffic to flow through the firewall.
|
Tip |
|---|---|
|
Make sure there are no preceding IP rule set entries that disallow the SIP traffic. |
SIP ALG Usage Scenarios
cOS Core supports a variety of SIP ALG usage scenarios. The following three scenarios cover nearly all possible types of usage:
Scenario 1
Protecting local clients - Proxy located on the Internet
The SIP session is between a client on the local, protected side of the Clavister firewall and a client which is on the external, unprotected side. The SIP proxy is located on the external, unprotected side of the firewall. Communication typically takes place across the Internet with clients on the internal, protected side registering with a proxy on the public, unprotected side.
Scenario 2
Protecting proxy and local clients - Proxy on the same network as clients
The SIP session is between a client on the local, protected side of the Clavister firewall and a client which is on the external, unprotected side. The SIP proxy is located on the local, protected side of the firewall and can handle registrations from both clients located on the same local network as well as clients on the external, unprotected side. Communication can take place across the Internet or between clients on the local network.
Scenario 3
Protecting proxy and local clients - Proxy on a DMZ interface
The SIP session is between a client on the local, protected side of the Clavister firewall and a client which is on the external, unprotected side. The SIP proxy is located on the DMZ interface and is physically separated from the local client network as well as the remote client network and proxy network.
All the above scenarios will also deal with the situation where two clients in a session reside on the same network. These scenarios will now be discussed in detail.
Scenario 1
Protecting local clients - Proxy located on the Internet
The SIP proxy in the above diagram could alternatively be located remotely across the Internet. The proxy should be configured with the Record-Route feature enabled to ensure all SIP traffic to and from the office clients will be sent through the SIP Proxy. This is recommended since the attack surface is minimized by allowing only SIP signaling from the SIP Proxy to enter the local network.
This scenario can be implemented in two ways:
Using NAT to hide the network topology.
Without NAT so the network topology is exposed.
|
Note: NAT traversal should not be configured |
|---|---|
|
SIP User Agents and SIP Proxies should not be configured to employ NAT Traversal in any setup. For instance the Simple Traversal of UDP through NATs (STUN) technique should not be used. The cOS Core SIP ALG will take care of all NAT traversal issues in a SIP scenario. |
The setup steps for this scenario are as follows:
Define a SIP ALG object using the options described above.
Define a Service object and associate it with the SIP ALG object. The service should have the following properties:
Define two IP rule set entries:
A NAT entry for outbound traffic from clients on the internal network to the SIP Proxy Server located externally. The SIP ALG will take care of all address translation needed by the NAT rule. This translation will occur both on the IP level and the application level. Neither the clients or the proxies need to be aware that the local users are being NATed.
An Allow entry for inbound SIP traffic from the SIP proxy to the IP of the firewall. This rule will use core (in other words, cOS Core itself) as the destination interface. This is because of the NAT rule above. When an incoming call is received, cOS Core will automatically locate the local receiver, perform address translation and forward SIP messages to the receiver. This will be executed based on the ALGs internal state.
A SAT rule set entry for translating incoming SIP messages is not needed since the ALG will automatically redirect incoming SIP requests to the correct internal user. When a SIP client behind a NATing firewall registers with an external SIP proxy, cOS Core sends its own IP address as contact information to the SIP proxy. cOS Core registers the client's local contact information and uses this to redirect incoming requests to the user. The ALG takes care of the address translations needed.
The IP rule set entries with the Record-Route option enabled would be as shown below, the changes that apply when NAT is used are shown in parentheses "(..)".
| Action | Src Interface | Src Network | Dest Interface | Dest Network |
|---|---|---|---|---|
| Allow (or Allow/NAT) |
lan | lan_net | wan | ip_proxy |
| Allow | wan | ip_proxy | lan (or core) |
lan_net (or wan_ip) |
Without the Record-Route option enabled the IP rule set entries would be as shown below, the changes that apply when NAT is used are again shown in parentheses "(..)".
| Action | Src Interface | Src Network | Dest Interface | Dest Network |
|---|---|---|---|---|
| Allow (or Allow/NAT) |
lan | lan_net | wan | <All possible IPs> |
| Allow | wan | <All possible IPs> | lan (or core) |
lan_net (or ipwan) |
The advantage of using Record-Route is clear since now the destination network for outgoing traffic and the source network for incoming traffic have to include all IP addresses that are possible.
|
Note: Tables omit the Service object |
|---|---|
|
In this section, tables which list IP rule set entries like those above, will omit the SIP Service object associated with each entry. However, the same, custom SIP Service object can be used for all SIP scenarios. |
Example 6.17. SIP with Local Clients/Internet Proxy Using IP Policies
This example shows the steps to implement Scenario 1 which is described above. The local network topology is hidden using NAT. The proxy server lies on the external, unprotected side of the Clavister firewall.
The client is assumed to be on the network if1_net connected to the interface if1. The SIP proxy is assumed to be on the IP address proxy_ip on the interface ext.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Define the required IP objects:
B. Define a VoIP Profile object:
C. Define a custom Service object for SIP:
D. Define the IP Policy for outgoing SIP traffic:
E. Define the IP Policy for incoming SIP traffic:
Scenario 2
Protecting proxy and local clients - Proxy on the same network as clients
This scenario can be implemented in two ways:
Using NAT to hide the network topology.
Without NAT so the network topology is exposed.
Solution A - Using NAT
Here, the proxy and the local clients are hidden behind the IP address of the Clavister firewall. The setup steps are as follows:
Define a Service object and associate it with the SIP ALG object. The service should have the following properties:
A NAT entry for outbound traffic from the local proxy and the clients on the internal network to the remote clients on, for example, the Internet. The SIP ALG will take care of all address translation needed by the NAT rule. This translation will occur both on the IP level and the application level. Neither the clients or the proxies need to be aware that the local clients are being NATed.
If Record-Route is enabled on the SIP proxy, the source network of the NAT rule can include only the SIP proxy, and not the local clients.
A SAT entry for redirecting inbound SIP traffic to the private IPv4 address of the NATed local proxy. This rule will have core as the destination interface (in other words, cOS Core itself) since inbound traffic will be sent to the private IPv4 address of the SIP proxy.
| SIP Traffic Type | Action | Src Interface | Src Network | Dest Interface | Dest Network |
|---|---|---|---|---|---|
| OutboundFrom ProxyUsers |
Allow/NAT | lan | lan_net (ip_proxy) |
wan | all-nets |
| InboundTo ProxyAndClients |
Allow/SAT Dest IP: ip_proxy |
wan | all-nets | core | wan_ip |
If Record-Route is enabled then the Source Network for outbound traffic from proxy users can be further restricted in the above by using "ip_proxy" as indicated.
When an incoming call is received, the SIP ALG will follow the SAT rule and forward the SIP request to the proxy server. The proxy will in turn, forward the request to its final destination which is the client.
If Record-Route is disabled at the proxy server, and depending on the state of the SIP session, the SIP ALG may forward inbound SIP messages directly to the client, bypassing the SIP proxy. This will happen automatically without further configuration.
Solution B - Without NAT
Without NAT, the outbound NAT IP rule set entry is replaced by an Allow entry. The inbound SAT and Allow IP rule set entries are replaced by a single Allow entry.
| Action | Src Interface | Src Network | Dest Interface | Dest Network | |
|---|---|---|---|---|---|
| OutboundFrom Proxy&Clients |
Allow | lan | lan_net (ip_proxy) |
wan | all-nets |
| InboundTo Proxy&Clients |
Allow | wan | all-nets | lan | lan_net (ip_proxy) |
If Record-Route is enabled then the networks in the above can be further restricted by using "(ip_proxy)", as indicated.
Scenario 3
Protecting proxy and local clients - Proxy on the DMZ interface
The complexity is increased in this scenario since SIP messages flow across three interfaces: the receiving interface from the call initiator, the DMZ interface towards the proxy and the destination interface towards the call terminator. The initial messages exchanges that take place when a call is setup in this scenario are illustrated below:
The exchanges illustrated in the above diagram are as follows:
1,2 - An initial INVITE is sent to the outbound local proxy server on the DMZ.
3,4 - The proxy server sends the SIP messages towards the destination on the Internet.
5,6 - A remote client or proxy server replies to the local proxy server.
7,8 - The local proxy forwards the reply to the local client.
This scenario can be implemented in a topology hiding setup with DMZ (Solution A below) as well as a setup without NAT (Solution B below).
Solution A - Using NAT
The following should be noted about this setup:
The IP address of the SIP proxy must be a globally routable IP address. cOS Core does not support hiding of the proxy on the DMZ.
The IP address of the DMZ interface must be a globally routable IP address. This address can be the same address as the one used on the external interface.
The setup steps are as follows:
Define a single SIP ALG object using the options described above.
Define a Service object and associate it with the SIP ALG object. The service should have the following properties:
Define four IP rule set entries:
A NAT entry for outbound traffic from the clients on the internal network to the proxy located on the DMZ interface. The SIP ALG will take care of all address translation needed by the NAT rule. This translation will occur both at the IP level and at the application level.
|
Note |
|---|---|
|
Clients registering with the proxy on the DMZ will have the IP address of the DMZ interface as the contact address. |
An Allow entry for outbound traffic from the proxy behind the DMZ interface to the remote clients on the Internet.
An Allow IP rule set entry for inbound SIP traffic from the SIP proxy behind the DMZ interface to the IP address of the firewall. This will have core (in other words, cOS Core itself) as the destination interface.
The reason for this is because of the NAT rule set entry above. When an incoming call is received, cOS Core automatically locates the local receiver, performs address translation and forwards SIP messages to the receiver. This is done based on the SIP ALG's internal state.
An Allow IP rule set entry for inbound traffic from, for example the Internet, to the proxy behind the DMZ.
If Record-Route is not enabled at the proxy, direct exchange of SIP messages must also be allowed between clients, bypassing the proxy. The following additional IP rule set entries are therefore needed when Record-Route is disabled:
A NAT entry for outbound traffic from the clients on the internal network to the external clients and proxies on, for example, the Internet. The SIP ALG will take care of all address translation needed by the NAT entry. The translation will occur both at the IP level and the application level.
An Allow rule set entry for inbound SIP traffic from, for example the Internet, to the IP address of the DMZ interface. The reason for this is because local clients will be NATed using the IP address of the DMZ interface when they register with the proxy located on the DMZ.
This IP rule set entry has core as the destination interface (in other words, cOS Core itself). When an incoming call is received, cOS Core uses the registration information of the local receiver to automatically locate this receiver, perform address translation and forward SIP messages to the receiver. This will be done based on the internal state of the SIP ALG.
The IP rule set entries needed with Record-Route enabled are:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | |
|---|---|---|---|---|---|
| OutboundToProxy | Allow/NAT | lan | lan_net | dmz | ip_proxy |
| OutboundFromProxy | Allow | dmz | ip_proxy | wan | all-nets |
| InboundFromProxy | Allow | dmz | ip_proxy | core | dmz_ip |
| InboundToProxy | Allow | wan | all-nets | dmz | ip_proxy |
With Record-Route disabled, the following IP rule set entries must be added to those given above:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | |
|---|---|---|---|---|---|
| OutboundBypassProxy | Allow/NAT | lan | lan_net | wan | all-nets |
| InboundBypassProxy | Allow | wan | all-nets | core | ipdmz |
Solution B - Without NAT
The setup steps are as follows:
Define a single SIP ALG object using the options described above.
Define a Service object which is associated with the SIP ALG object. The service should have the following properties:
Define the following IP rule set entries:
An Allow IP rule set entry for outbound traffic from the clients on the internal network to the proxy located on the DMZ interface.
An Allow IP rule set entry for outbound traffic from the proxy behind the DMZ interface to the remote clients on the Internet.
An Allow IP rule set entry for inbound SIP traffic from the SIP proxy behind the DMZ interface to the clients located on the local, protected network.
An Allow IP rule set entry for inbound SIP traffic from clients and proxies on the Internet to the proxy behind the DMZ interface.
If Record-Route is not enabled at the proxy, direct exchange of SIP messages must also be allowed between clients, bypassing the proxy. The following two additional rules are therefore needed when Record-Route is disabled:
An Allow IP rule set entry for outbound traffic from the clients on the local network to the external clients and proxies on the Internet.
An Allow IP rule set entry for inbound SIP traffic from the Internet to clients on the local network.
The IP rule set entries with Record-Route enabled are as shown below:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | |
|---|---|---|---|---|---|
| OutboundToProxy | Allow | lan | lan_net | dmz | ip_proxy |
| OutboundFromProxy | Allow | dmz | ip_proxy | lan | lan_net |
| InboundFromProxy | Allow | dmz | ip_proxy | core | dmz_ip |
| InboundToProxy | Allow | wan | all-nets | dmz | ip_proxy |
With Record-Route disabled, the following IP rule set entries must be added to those above:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | |
|---|---|---|---|---|---|
| OutboundBypassProxy | Allow | lan | lan_net | wan | all-nets |
| InboundBypassProxy | Allow | wan | all-nets | lan | lan_net |
SIP ALG Setup Using IP Rules
This section repeats the examples given previously but uses IP rules instead of IP policies to deploy the SIP ALG.When configuring cOS Core for SIP sessions using IP rules, the following steps are required:
Define a new SIP ALG object. Configurations upgraded from a version prior to cOS Core 11.03.00 may have a predefined SIP ALG object that could be used instead but creating a custom service is recommended.
Define a single Service object for SIP communication and associate it with the ALG.
Define the appropriate IP Rule or IP Policy objects for SIP communications which uses the defined Service object.
Example 6.18. SIP with Local Clients/Internet Proxy Using IP Rules
This example repeats Example 6.17, “SIP with Local Clients/Internet Proxy Using IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Define the following IP objects:
B. Define a SIP ALG object
C. Define a custom Service object for SIP:
D. Define the IP rule for outgoing SIP traffic:
E. Define the IP Rule for incoming SIP traffic:
Overview
H.323 is a standard approved by the International Telecommunication Union (ITU) to allow compatibility in video conference transmissions over IP networks. It is used for real-time audio, video and data communication over packet-based networks such as the Internet. It specifies the components, protocols and procedures for providing such multimedia communication, including Internet phone and voice-over-IP (VoIP). (For VoIP see also Section 6.1.9, SIP ALG.)H.323 Components
H.323 consists of four main components:H.323 ALG features
The H.323 ALG is a flexible application layer gateway that allows H.323 devices such as H.323 phones and applications to make and receive calls between each other when connected via private networks secured by Clavister firewalls.The H.323 specification was not designed to handle NAT, as IP addresses and ports are sent in the payload of H.323 messages. The H.323 ALG modifies and translates H.323 messages to make sure that H.323 messages will be routed to the correct destination and allowed through the firewall.
H.323 handling by cOS Core has the following characteristics:
cOS Core supports version H.323 version 5 of the H.323 specification. This specification is built upon H.225.0 v5 and H.245 v10.
In addition to support voice and video calls, cOS Core supports application sharing over the T.120 protocol. T.120 uses TCP to transport data while voice and video is transported over UDP.
To support gatekeepers, cOS Core monitors RAS traffic between H.323 endpoints and the gatekeeper, in order to correctly configure the firewall to let calls through.
NAT and SAT IP rule set entries are supported, allowing clients and gatekeepers to use private IPv4 addresses on a network behind the firewall.
Methods of Setting up the H.323 ALG
Deploying the H.323 ALG can be done using one of the following methods:Using a VoIP Profile object with an IP Policy object
The H.323 ALG can be configured using IP Policy objects and this is the recommended method. Setup is done by creating a VoIP Profile object and specifying the H.323 options on that. The VoIP Profile object is then associated with an IP Policy object that triggers on the target traffic.
A Service object configured for H.323 traffic must also be used with the IP Policy object. This Service object must have its Protocol property set to H.323.
The predefined H.323 service objects in the default configuration for cOS Core 11.03 and later already have their Protocol property set to be H.323. This will not be true where cOS Core has been upgraded to version 11.03 or later.
Using an H.323 ALG object with an IP Rule object
Alternatively, an H.323 ALG object can be associated with a Service object configured for the H.323 protocol. The service object is then used with the IP Rule objects that control H.323 traffic flow.
In cOS Core version 11.03 and later, a predefined H.323 ALG is not present in the default configuration and therefore a new H.323 ALG object must always be created when using an IP Rule object with H.323. In older cOS Core versions that are upgraded to 11.03 or later, the predefined H.323 ALG object will be retained.
Allow TCP Data Channels
This option allows TCP based data channels to be negotiated. Data channels are used, for example, by the T.120 protocol.
Max TCP Data Channels
The maximum number of TCP data channels can be specified.
Max Gatekeeper Registration Lifetime
The gatekeeper registration lifetime can be controlled in order to force re-registration by clients within a certain time. A shorter time forces more frequent registration by clients with the gatekeeper and less probability of a problem if the network becomes unavailable and the client thinks it is still registered.
Translate Addresses
The default value for address translation is Automatic. If set to Specific, a particular network and IP address can be set. If not enabled then no address translation will be done on logical channel addresses and the administrator needs to be sure about IP addresses and routes used in a particular scenario.
Network and IP Address
This option is available if the Translate Address option is set to Specific. For NATed traffic, the Network specifies what is allowed to be translated. The IP Address specifies which IPv4 address to NAT with. If Translate Addresses is to Automatic, the external IP address is found automatically through route lookup.
Channel setup mode
This can either be set to Optimistic (the default) or Normal. The Optimistic setting means that the logical H.323 channel is opened when only a single direction is established. The Normal setting means that a bidirectional connection must be established before the logical channel is opened.
If using IP rules instead of properties, the above properties are available directly on the H.323 ALG object.
H.323 Service Object Setup
When creating IP rule set entries that target H.323, a Service object is required that targets the protocol. The properties of the Service object created for H.323 should be as follows:H.323 Service - Type: TCP, Destination port: 1720
H.323 Gatekeeper Service - Type: UDP, Destination port: 1719
When using IP Policy objects, the Protocol property of the associated service must be set to H.323 for the H.323 ALG to become available for activation.
There are predefined Service objects in cOS Core which are called h323 and h323-gatekeeper and these could be used instead of the custom Service objects used in the examples. However, if using these objects with an IP Policy, it should be checked that the Protocol property of the Service is set to H.323. This is automatically true for the default configuration of cOS Core 11.03 or later but not true for upgrades from versions prior to 11.03.
H.323 ALG Setup Examples Using IP Policies
The following examples illustrate how to set up the H.323 ALG using IP Policy objects in the IP rule set in various scenarios.Example 6.19. Protecting Internal H.323 Phones Using IP Policies
In this example, an internal H.323 phone is situated on lan_net and has a public IP address. To make it possible to place a call from this phone to another H.323 phone on the Internet and to allow H.323 phones on the Internet to call this phone, IP rule set entries need to be added.
Note: Make sure there are no other IP rule set entries disallowing or allowing the same kind of ports/traffic before the entries in this example.
Note that the Service object used must have its Protocol property set to be H.323.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for H.323:
Create an IP policy for outgoing H.323 traffic:
Create an IP policy for incoming H.323 traffic:
Example 6.20. H.323 with a Private Address Using IP Policies
In this example, an internal H.323 phone is on a network with private IPv4 addresses. To make make a call from this phone to another H.323 phone on the Internet and to allow H.323 phones on the Internet to call this phone, IP rule set entries need to be added.
Note: Make sure there are no IP rule set entries disallowing or allowing the same kind of traffic before these entries.
When using private IPs on the phone, incoming traffic needs to be SATed, as in the example below. The IPv4 address object ip-phone is the internal IP of the H.323 phone.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for H.323:
Create the outgoing IP policy:
Create the SAT IP policy for incoming H.323 traffic:
To place a call to the phone behind the Clavister firewall, place a call to the external IP address on the firewall. If multiple H.323 phones are placed behind the firewall, one SAT IP rule set entry has to be configured for each phone. This means that multiple external addresses have to be used. However, it is better to use an H.323 gatekeeper as this only requires one external address.
Example 6.21. Two Phones Behind Different Firewalls Using IP Policies
This scenario consists of two H.323 phones, each one connected behind the Clavister firewall on a network with public IPv4 addresses. In order to place calls on these phones over the Internet, entries need to be added to the IP rule sets of both firewalls. Make sure there are no IP rule set entries disallowing or allowing the same kind of ports/traffic before these entries.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for H.323:
Create an IP policy for outgoing traffic:
Create the IP policy for incoming traffic:
Example 6.22. Using Private IPv4 Addresses with IP Policies
This scenario consists of two H.323 phones, each one connected behind the Clavister firewall on a network with private IPv4 addresses. In order to place calls on these phones over the Internet, entries need to be added to the IP rule set in the firewall. Make sure there are no rule set entries disallowing or allowing the same kind of ports/traffic before these entries.
As we are using private IPs on the phones, incoming traffic need to be SATed as in the example below. The object ip-phone should be the internal IP of the H.323 phone behind each firewall.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for H.323:
Create the outgoing traffic NAT IP policy:
Create the SAT IP policy for incoming traffic:
To place a call to the phone behind the firewall, place a call to the external IP address of the firewall. If multiple H.323 phones are placed behind the firewall, one SAT IP rule set entry has to be configured for each phone. This means that multiple external addresses have to be used. It is better to use an H.323 gatekeeper as this only requires one external address.
Example 6.23. H.323 with Gatekeeper Using IP Policies
In this scenario, an H.323 gatekeeper is placed in the DMZ connected to the firewall. An IP policy is configured in the firewall to allow traffic between the private network where the H.323 phones are connected on the internal network and to the gAtekeeper on the DMZ. The gatekeeper on the DMZ is configured with a private address.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for the H.323 gatekeeper:
Create the SAT IP policy for incoming gatekeeper traffic:
Create the IP policy that allows traffic from lan_net to the gatekeeper:
|
Note: Outgoing calls do not need a specific IP policy |
|---|---|
|
There is no need to specify a specific IP rule set entry for outgoing calls. cOS Core monitors the communication between "external" phones and the Gatekeeper to make sure that it is possible for internal phones to call the external phones that are registered with the gatekeeper. |
Example 6.24. H.323 with Gatekeeper and two Clavister Firewalls
This scenario is quite similar to the previous example, with the difference that the Clavister firewall is protecting the "external" phones. The firewall with the gatekeeper connected to the DMZ should be configured exactly as in the previous example. The other firewall should be configured as below. IP rule set entries need to be added and there should not be other entries disallowing or allowing the same kind of ports/traffic before these entries.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for the H.323 gatekeeper:
Create a NAT IP policy for outgoing gatekeeper traffic from lan_net to the Internet:
|
Note: Outgoing calls do not need a specific IP policy |
|---|---|
|
There is no need to specify a specific IP policy for outgoing calls. cOS Core monitors the communication between "external" phones and the Gatekeeper to make sure that it is possible for internal phones to call the external phones that are registered with the gatekeeper. |
Example 6.25. Using H.323 in an Enterprise Environment
This is an example of a more complex situation that shows how the H.323 ALG can be deployed in an enterprise environment. At the head office DMZ is an H.323 gatekeeper that can handle all H.323 clients in the head, branch and remote offices. This will allow the whole enterprise to use the network for both voice communication and application sharing.
It is assumed that the VPN tunnels are correctly configured and that all offices use private IP ranges on their local networks. All outside calls are made over the existing telephone network using the gateway (ip-gateway) which is connected to the ordinary telephone network.
The head office has placed an H.323 Gatekeeper in the DMZ of the corporate Clavister firewall. This firewall should be configured as follows:
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new VoIP Profile object:
Create a custom Service object for the H.323 gatekeeper:
Create an IP policy for traffic from lan_net to gatekeeper:
Create an IP policy for traffic from the gateway to internal phones on lan_net:
Create an IP policy for traffic from the gateway to internal phones on lan_net:
Create an IP policy for traffic from the VPN to the gatekeeper:
Example 6.26. Configuring remote offices for H.323
If the branch and remote office H.323 phones and applications are to be configured to use the H.323 gatekeeper at the head office, the Clavister firewalls in the remote and branch offices should be configured as follows:
Here, the interface called vpn-hq is the VPN tunnel to the network hq-net located at headquarters.
Note: This IP policy should exist in both the branch and remote office cOS Core configurations.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 6.27. Allowing the H.323 Gateway to register with the Gatekeeper
The branch office Clavister firewall has an H.323 gateway connected to its DMZ. In order to allow the H.323 gateway to register with the H.323 gatekeeper at the Head Office, the following has to be configured:
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
|
Note: Outgoing calls do not need a specific IP policy |
|---|---|
|
There is no need to specify a specific IP rule set entry for outgoing calls. cOS Core monitors the communication between "external" phones and the gatekeeper to make sure that it is possible for internal phones to call the external phones that are registered with the gatekeeper. |
H323 ALG Examples Using IP Rules
The following examples repeat the examples in this section but use IP Rule objects instead of IP Policy objects. Using IP policies is the recommended method for H323 ALG setup. These examples are included for completeness.Example 6.28. Protecting Internal H.323 Phones Using IP Rules
This example repeats Example 6.19, “Protecting Internal H.323 Phones Using IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for H.323:
Create an IP rule for outgoing H.323 traffic:
Create an IP rule for incoming H.323 traffic:
Example 6.29. H.323 with a Private Address Using IP Rules
This example repeats Example 6.20, “H.323 with a Private Address Using IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for H.323:
Create the outgoing IP rule:
Create the SAT IP rules for incoming H.323 traffic:
Example 6.30. Two Phones Behind Different Firewalls Using IP Rules
This example repeats Example 6.21, “Two Phones Behind Different Firewalls Using IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for H.323:
Create the outgoing traffic IP rule:
Create the incoming traffic IP rule:
Example 6.31. Using Private IPv4 Addresses - IP Rules Version
This example repeats Example 6.22, “Using Private IPv4 Addresses with IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for H.323:
Create the outgoing traffic NAT IP rule:
Create the incoming traffic SAT IP rules:
Example 6.32. H.323 with Gatekeeper Using IP Rules
This example repeats Example 6.23, “H.323 with Gatekeeper Using IP Policies” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for the H.323 gatekeeper:
Create the SAT IP rules for incoming gatekeeper traffic:
Create the IP rule that allows traffic from lan_net to the gatekeeper:
Example 6.33. H.323 with Gatekeeper and two Clavister firewalls Using IP Rules
This example repeats Example 6.24, “H.323 with Gatekeeper and two Clavister Firewalls” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for the H.323 gatekeeper:
Create a NAT IP policy for outgoing gatekeeper traffic from lan_net to the Internet:
Example 6.34. Using H.323 in an Enterprise Environment
This example repeats Example 6.25, “Using H.323 in an Enterprise Environment” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a new H.323 ALG object:
Create a custom Service object for the H.323 gatekeeper:
Create an IP rule for traffic from lan_net to gatekeeper:
Create an IP rule for traffic from the gateway to internal phones on lan_net:
Create an IP rule for traffic from the gateway to internal phones on lan_net:
Create an IP rule for traffic from the VPN to the gatekeeper:
Example 6.35. Configuring remote offices for H.323 Using IP Rules
This example repeats Example 6.26, “Configuring remote offices for H.323” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 6.36. Allowing the H.323 Gateway to register with the Gatekeeper Using IP Rules
This example repeats Example 6.27, “Allowing the H.323 Gateway to register with the Gatekeeper” but uses IP rules instead of IP policies.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Overview
Transport Layer Security (TLS) is a protocol that provides secure communications over the Internet between two endpoints through the use of cryptography as well as providing endpoint authentication.Typically in a TLS client/server scenario, only the identity of the server is authenticated before encrypted communication begins. TLS is very often encountered when a web browser connects with a server that uses TLS, such as when a customer accesses online banking facilities. This is sometimes referred to as an HTTPS connection and is often indicated by a padlock icon appearing in the browser's navigation bar.
TLS can provide a convenient and simple solution for secure access by clients to servers and avoids many of the complexities of other types of VPN solutions such as using IPsec. Most web browsers support TLS and users can therefore easily have secure server access without requiring additional software.
cOS Core Supports TLS, Not SSL
TLS is a successor to the Secure Sockets Layer (SSL) but the differences are slight. For most purposes, TLS and SSL can be regarded as equivalent. However, cOS Core only supports TLS and any reference to SSL in cOS Core documentation should be assumed to be referring to TLS. The TLS ALG can be said to provide SSL termination since it is acting as an SSL endpoint.Cryptographic Suites and TLS Version Supported by cOS Core
cOS Core supports a number of cryptographic algorithms for SSL VPN. Only some are enabled by default and all can be either enabled or disabled. All the supported algorithms are listed in Section 13.9, SSL/TLS Settings. Note that TLS version 1.0 and 1.2 is supported by cOS Core but not version 1.1. Refer to Section 13.9, SSL/TLS Settings for how to disable version 1.2 so only 1.0 can be used.Note that both the cOS Core TLS ALG as well as cOS Core SSL VPN do not support TLS renegotiation (defined by RFC-5746).
TLS is Certificate Based
TLS security is based on the use of digital certificates which are present on the server side and sent to a client at the beginning of a TLS session in order to establish the server's identity and then be the basis for encryption. Certificates which are Certificate Authority (CA) signed can be used on the server in which case a client's web browser will automatically recognize the validity of the certificate.Self-signed certificates can be used instead of CA signed certificates on the server. With self-signed certificates, the client's web browser will alert the user that the certificate's authenticity is not recognized and the user will have to explicitly tell the browser to accept the certificate and continue.
Advantages of Using cOS Core for TLS Termination
TLS can be implemented directly in the server to which clients connect, however, if the servers are protected behind a Clavister firewall, then the firewall can take on the role of the TLS endpoint. This is done by associating the TLS ALG with the IP rule entry that allows the traffic. cOS Core then performs TLS authentication, encryption and decryption of data to/from clients and the transfer of unencrypted data to/from servers. The IP rule set entry can also perform any address translation that is required.The advantages of this approach are the following:
TLS support can be centralized in the Clavister firewall instead of being set up on individual servers.
Certificates can be managed centrally in the firewall instead of on individual servers. Unique certificates (or one wildcard certificate) does not need to be present on each server.
The encryption/decryption processing overhead required by TLS can be offloaded to the firewall. This is sometimes referred to as SSL acceleration. Any processing advantages that can be achieved can, however, vary and will depend on the comparative processing capabilities of the servers and the firewall.
Decrypted TLS traffic can be subject to other cOS Core features such as traffic shaping or looking for server threats with IDP scanning.
TLS can be combined with cOS Core server load balancing to provide a means to spread traffic across servers.
URLs Delivered by HTTP Servers
It should be noted that using cOS Core for TLS termination will not change URLs in webpages delivered by web servers which lie behind the Clavister firewall.What this means is that if a client connects to a web server behind the Clavister firewall using the https:// protocol then any web pages delivered back containing absolute URLs with the http:// protocol (perhaps to refer to other pages on the same site) will not have these URLs converted to https:// by cOS Core. The solution to this issue is for the servers to use relative URLs instead of absolute ones.
Cryptographic Suites Supported by cOS Core TLS
cOS Core supports a number of cryptographic algorithms for TLS. These can be enabled or disabled globally using the advanced settings described in Section 13.9, SSL/TLS Settings.By default, only the four algorithms which are considered the most secure are enabled. It is not recommended to enable the weaker algorithms and they exist primarily for backwards compatibility.
TLS ALG Restrictions
The following are restrictions that exist when using the TLS ALG:Client authentication is not supported (where cOS Core authenticates the identity of the client).
Sending server key exchange messages is not supported which means the key in the certificate must be sufficiently weak in order to use export ciphers.
As mentioned previously, TLS renegotiation is not supported.
Methods of Setting Up the TLS ALG
Deploying the TLS ALG can be done using one of the following methods:Using an IP Policy object is the recommended setup method. The TLS ALG options are configured directly by setting properties of the IP policy. Note that to configure TLS options with an IP policy, the policy's Service property must be assigned a service object which has its Protocol property set to TLS.
Setting this up is described below but it is also described in an article in the Clavister Knowledge Base at the following link:
When using IP Rule objects, a TLS ALG object is associated with a Service object that is then associated with an IP rule.
This setup method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.
Setting up the TLS ALG Using an IP Policy
The steps for enabling TLS with an IP Policy are as follows:Upload the host and root certificates to be used with TLS to cOS Core, if not done already.
Create a new custom Service object based on the TCP protocol and set the Protocol property to TLS.
Create an IP Policy for the targeted traffic and associate the custom service object with it.
Enable TLS for the IP Policy and set the values on the policy for the host and root certificates to use. There can only be one host certificate but there can be multiple root certificates.
Using Self-signed Certificates
If the certificates used with the TLS ALG are self-signed then the root and host certificate should both be set to the same certificate.Example 6.37. TLS ALG Setup Using an IP Policy
In this an IP Policy object will be set up allows access to an internal web server from TLS clients on the Internet. The wan interface is connected to the Internet and has the IPv4 address wan_ip. The web server is located on a DMZ and has the private IPv4 address 10.0.0.5. This policy will perform SAT address translation.
It is assumed that the certificate files for my_root_cert and my_host_cert have already been uploaded to the firewall.
Command-Line Interface
A. Create a custom Service object for TLS:
Device:/> add Service ServiceTCPUDP my_tls_service
Type=TCP
DestinationPorts=443
Protocol=TLSB. Create a SAT IP Policy:
Device:/> add IPPolicy Name=SAT_TLS_To_DMZ
SourceInterface=wan
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=my_tls_service
Action=Allow
SourceAddressTranslation=None
DestinationAddressTranslation=SAT
DestinationAddressAction=SingleIP
DestNewIP=10.0.0.5
TLSControl=Yes
TLSHostCert=my_host_cert
TLSRootCert=my_root_certInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a custom Service object for TLS:
B. Create a SAT IP Policy:
Setting up the TLS ALG Using an IP Rule
An alternative but more indirect method for setting up the TLS ALG is to use an IP Rule instead of an IP Policy. The steps for doing this are as follows:Upload the host and root certificates to be used with TLS to cOS Core.
Define a new TLS ALG object and associate the appropriate host and root certificates with the ALG.
Create a new custom Service object based on the TCP protocol.
Associate the TLS ALG object with the newly created service object.
Create a NAT or Allow IP rule for the targeted traffic and associate the custom service object with it.
Optionally, a SAT rule can be created to change the destination port for the unencrypted traffic. Alternatively, an SLB_SAT rule can be used to do load balancing (the destination port can also be changed through a custom service object).
Overview
DNS queries can provide a means of attack for malicious third parties. The DNS ALG feature can be used to monitor DNS queries as they flow through the firewall in the following scenarios:DNS queries flowing to the Internet from protected clients behind the firewall.
DNS queries being sent, usually from the Internet, to a DNS server located on a DMZ behind the firewall.
Define a DNS Profile object
This object defines how the DNS ALG will behave for the targeted DNS connections. The DNS Profile object properties are described later in this section.
Associate the profile with an IP Policy for the targeted DNS traffic
The IP Policy must have the following two properties correctly set in order to use the DNS ALG:
Service
This should be a Service object that targets the DNS traffic. A predefined service object is provided called dns-all for all DNS traffic. Alternatively, use the predefined objects dns-udp or dns-tcp to target UDP and TCP DNS traffic. A custom service could be used instead. One service object can be shared across multiple IP policies.
Any Service object used with DNS must have its Protocol property set to the value DNS. If this is not the case, the DNS ALG will not be applied to a connection even though it is triggers the IP policy. The Protocol property is already correctly set for the predefined DNS service objects.
DNS Profile
This must be set to a DNS Profile object defined previously. One DNS Profile object can be shared across multiple IP policies and there is no limit on the number of connections handled by a single profile object.
Note that the DNS ALG cannot be used with IP Rule objects.
Name
A suitable descriptive name for the profile.
Log resolved DNS entries
When enabled (the default), a log message is generated for each DNS query that is resolved.
Populate the system's DNS-cache with IP addresses
When enabled (the default), each DNS query the passes through the profile will cause the resolved address to be entered into the DNS cache.
When using wildcards with FQDN Address objects, a DNS Profile must be associated with the allowing IP Policy and this property must be enabled. This is discussed further in Section 3.1.7, FQDN Address Objects.
Max UDP query length
The maximum allowed payload size in bytes for UDP DNS queries. The default value is 4096. Queries exceeding this size will be dropped and a log message generated.
Max UDP response length
The maximum allowed payload size in bytes for UDP DNS responses. The default value is 4096. Responses exceeding this size will be dropped and a log message generated. When using DNSSEC, the responses can be large so the default value should be increased.
Max TCP query length
The maximum allowed payload size in bytes for TCP DNS queries. The default value is 4096. Queries exceeding this size will be dropped and a log message generated.
Max TCP response length
The maximum allowed payload size in bytes for TCP DNS responses. The default value is 4096. Responses exceeding this size will be dropped and a log message generated. When using DNSSEC, the responses can be large so the default value should be increased.
DNS recursion means that a DNS server can query other servers to fully resolve the original query. DNS requests have a Recursion Desired (RD) flag which is typically set by, for example, client browsers.
By default, the Recursion Desired flag property is set to Allow so requests with the RD flag set are allowed, and this should be the settings when protected clients are sending requests to a public DNS server.
However, recursion could be used as a means to launch an amplification attack against a internal DNS server by sending fake DNS queries from a spoofed IP address. In this case, the Recursion Desired flag property could be set to a value of Drop to drop any DNS queries with the RD flag set.
Max question entries
The maximum number of question entries in a query. The default value is 1. It may be possible that a single DNS query might ask for resolution of more than one FQDN but this depends on how the client is configured.
Scramble query IDs
When enabled (the default) the transaction ID of DNS queries are randomized. This helps defend against cache poisoning caused by the spoofing of DNS queries using non-randomized IDs.
Allow all classes
This property is disabled by default.
Allowed classes
When Allow all classes is disabled (the default), this property is set to a list of the allowed classes. Classes can be specified using only their name. The default selection is IN (the Internet class).
Allow all types
This is enabled by default.
Allowed types
If Allow all types is disabled, this property is used to specify the allowed types. Types can be specified using only their name. No types are selected by default.
State Tracking is Always Enabled
The DNS ALG has state tracking always enabled and there is no setting to control this. State tracking means that DNS queries and responses are matched to each other. A response with no matching query is automatically dropped.Forms of DNS Attack and DNS ALG Defense Mechanisms
The DNS ALG is designed to provide a defense against the following forms of DNS attack:DNS Cache Poisoning
DNS cache poisoning relies on being able to spoof DNS responses, which means it is mainly applicable to DNS traffic over UDP. An attacker forges and sends a fake/spoofed response to a legitimate DNS query. If the DNS client that sent the original query accepts the faked response, this allows the attacker to inject false entries into the client's DNS cache. The DNS ALG will protect against this in multiple ways. For example, by using the Scramble query ID property of the DNS Profile object (making it more difficult for an attacker to generate a proper response) and also through query/response state tracking (which drops unexpected responses and is always enabled).
In addition, the Recursion Desired flag property of the DNS Profile object can be used to prevent DNS clients from sending queries which request recursion.
DNS Reflection/Amplification Attacks
In this scenario, a DNS server is used to reflect and/or amplify traffic. An attack can be performed in different ways but generally relies on UDP for the spoofing of the source address of the attack victims. An attacker will generate a large amount of DNS queries to one or more DNS servers which will all respond to the spoofed address. Typically, the attacker will craft the spoofed DNS queries in a way that they will not only reflect, but also amplify traffic (for example, by asking many questions in a single query).
The DNS ALG can help protect against this using the following DNS Profile object properties:
DNS Tunneling
In this scenario, an attacker uses DNS traffic to tunnel data through the firewall. The DNS ALG provides protection against basic tunneling by only allowing well-formed DNS traffic through. This means that cOS Core validates the DNS traffic against the protocol description in the relevant RFCs. Non-conforming data traffic will be dropped.
More sophisticated tunneling attacks might encode data as valid domain names and store it in the DNS queries/responses. This is difficult to detect. The DNS ALG provides a degree of protection against this using the following DNS Profile object properties:
Device:/> dnscontrol -stats
DNS Control statistics
--------------------------------------
Forwarded DNS Queries : 2411
Forwarded DNS Responses : 2393
Malformed Client Messages : 6
Malformed Server Messages : 12
Dropped Client Messages : 6
Dropped Server Messages : 12
Current DNS Session : 0
Total DNS Sessions : 2401Device:/> dnscontrol -list
DNS Control Sessions
ID Creation time Outstanding Transactions
----- -------------------- ------------------------
2002 2021-05-14 08:15:14 0
2003 2021-05-14 08:15:14 1
2004 2021-05-14 08:15:14 1Each DNS query passing through any DNS Profile is assigned a unique ID number, in an ascending sequence.
The Creation time indicates the time when the profile forwarded the DNS query to the DNS server.
A number greater than one in the Outstanding Transactions column indicates if any replies from a query to a DNS server are outstanding.
When all outstanding replies are received then the number outstanding becomes zero but there may be a delay before cOS Core removes the query from the list. This is the case with the ID 2002 query in the list above.
To show more information about outstanding queries, the -list option can be used together with the -verbose option, as shown in the example below:
Device:/> dnscontrol -list -verbose
DNS Control Sessions
ID Creation time Outstanding Transactions
----- -------------------- ------------------------
2011 2021-06-14 09:18:14 1
UDP
192.26.2.2:36318->192.26.1.2:53 [FW] 192.26.2.2:36318->192.26.1.2:53In the above, a single DNS query is outstanding but this time additional detail is provided to show the protocol used (UDP in this case) and the address translation (if any) performed during DNS forwarding by cOS Core. In the above query, the source client address of the query was 192.26.2.2:36318 and the destination server address was 192.26.1.2:53, with no translation being performed. If the connection was subject to a NAT or SAT translation then this would show up with the -verbose option.
All the options for the dnscontrol command can be found in the separate CLI Reference Guide.
Note that the statistics provided by the dnscontrol command are not available in the cOS Core Web Interface.
Example 6.38. Using the DNS ALG with a Protected DNS Server
In this example, the DNS ALG is used to filter UDP DNS queries sent to a protected DNS server on a DMZ which are coming from the Internet. This is illustrated in the diagram below.
DNS recursion will be disabled to protect the DNS server.
Command-Line Interface
Create a DNSProfile:
Device:/> add Policy DNSProfile my_internal_dns_server_alg
RecursionDesiredFlag=Drop
Create a SAT IP policy that uses the profile:
Device:/> InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a DNS Profile:
Create a SAT IP policy that uses the profile:
Example 6.39. Using the DNS ALG with Protected Clients
In this example, clients on the internal protected network lan_net are sending DNS queries out to the Internet using NAT via the interface wan. This is illustrated in the diagram below:
All DNS classes will be allowed and DNS recursion should also be allowed.
Create a DNSProfile with default values:
Device:/> add Policy DNSProfile my_external_dns_server_alg
RecursionDesiredFlag=Allow
AllowAllClasses=Yes
Create an IPPolicy that uses the profile:
Device:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create a DNS Profile with default values:
Create an IP policy that uses the profile:
The Syslog ALG can perform checks on Syslog messages passing through the firewall. It can drop some messages as well as add user identity information to others. The ALG is not used with Syslog messages generated by the local firewall itself.
Syslog ALG Setup
The Syslog ALG is set up using the following steps:Create a new Service TCP/UDP object that has the following settings:
Alternatively, the predefined syslog service could be used but if this is done, the Protocol property of the object must be set to the value SYSLOG.
Create a new Syslog Profile object that defines the type of processing to be performed by cOS Core on the targeted Syslog traffic. The mandatory properties of this object are described below.
Create a new IP Policy object that allows the targeted Syslog traffic. The Service property of the policy's filter must be set to the service created in the first step. The Syslog Profile created in the previous step must also be assigned to the policy.
Note that instead of an IP Policy, an SLB Policy could be used. The Syslog ALG cannot be set up using IP rule objects.
If the option requiring authentication in the ALG is enabled, user authentication for the originating IP addresses of Syslog traffic will also have to be configured.
Syslog Profile Object Properties
A Syslog Profile object has the following key properties:Enabling this option means that the source of the message must be from a user that has been authenticated by cOS Core. If this option is enabled and the source is not authenticated then the message is dropped. Authentication could have been performed using any of the methods available in cOS Core and these are discussed further in Chapter 9, User Authentication. This option is disabled by default.
Append Tag
This option can be enabled to append extra informational data to the Syslog message. One of the following options can be chosen for the appended data:
Username - The username of the authenticated user.
Recv Iface Name - The receiving interface of the connection.
The appended data will always be surrounded by double quotation marks and have a preceding space character. For example:
"myusername"
Note that if the tag option Username is selected and the source IP is not authenticated by cOS Core then the appended tag will take the value n/a.
Tag Prefix
If the username or receive interface is being appended, the optional Tag Prefix property can also be used to specify a prefix for the appended data. The tag prefix chosen should not be a string that might appear in any of the messages processed. For example, if the username is appended and the its value is myusername then the tag prefix could be specified as Authenticated_Username=. The appended text would then appear as the following:
Authenticated_Username="myusername"
Note that the tag prefix also has a preceding space automatically inserted before it. It also has a maximum length of 15 characters and cannot contain spaces.
If this option is enabled then between one and four prohibited keywords can be specified. If a Syslog message contains any of these keywords then it is dropped. The option can help guard against spurious data being inserted into a message. By default, the option is disabled.
If the Syslog message payload exceeds this size in bytes, the message is dropped. The default value is 4096 bytes. This option is always enabled.
Any Return Traffic Will Close the Connection
Syslog traffic is one directional and there should be no traffic going in the return direction. If the Syslog ALG detects any returning traffic, the traffic is dropped and the connection is closed.Example 6.40. Syslog ALG Setup with an IP Policy
In this example, Syslog traffic flowing between interfaces If1 and If2 will be scanned using a Syslog Profile.
The following is required for the Syslog messages processed:
The source IP of all messages must be authenticated by cOS Core, otherwise the message will be dropped.
The authenticated username will be appended to all messages and have the prefix "Authenticated_UserID=".
Syslog messages will be dropped if they contain either the keyword "test" or "debug".
The maximum allowed message size is to be 8192 bytes, otherwise the message is dropped.
Although authentication of the message source IP is required in this example, configuring authentication itself is not described. However, this could be done using any of the methods available in cOS Core.
Command-Line Interface
A. Create a new Service object for the Syslog traffic:
Device:/> add Service ServiceTCPUDP my_syslog_service
Type=UDP
DestinationPorts=514
Protocol=SYSLOGB. Create a SyslogProfile object:
Device:/> add Policy SyslogProfile my_syslog_profile
RequireAuth=Yes
AppendAuthName=Yes
AuthNamePrefix="Authenticated_UserID="
DenyProhibitedKeywords=Yes
ProhibitedKeywords=test,debug
MaxSyslogLength=8192C. Create an IP Policy for Syslog traffic:
Device:/> add IPPolicy Name=my_syslog_policy
SourceInterface=If1
SourceNetwork=If1_net
DestinationInterface=If2
DestinationNetwork=If2_net
Service=my_syslog_service
Action=Allow
SyslogControl=Yes
Syslog_Policy=my_syslog_profileInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a new Service object for the Syslog traffic:
B. Create a Syslog Profile object:
C. Create an IP Policy for Syslog traffic:
