| Home Prev |  cOS Core 14.00.17 Administration Guide
|
Next |
|---|
A Service object is a reference to a specific IP protocol with associated parameters. A service definition is usually based on one of the major transport protocols such as TCP or UDP which is associated with a specific source and/or destination port number(s). For example, the HTTP service is defined as using the TCP protocol with the associated destination port 80 and any source port.
However, service objects are not restricted to just the TCP or UDP protocols. They can be used to encompass ICMP messages as well as a user-definable IP protocol.
A Service is Passive
Services are passive cOS Core objects in that they do not themselves carry out any action in the configuration. Instead, service objects must be associated with the security policies defined by various cOS Core rule sets and then act as a filter to apply those rules only to a specific type of traffic.For example, many security policies have a service object associated with them as a filtering parameter to decide if the rule should trigger on a particular protocol. Being part of the filter for IP rule set entries is one the most important usage of service objects.
For an IP Rule object, the Service property is how an ALG becomes associated with the rule. The ALG is associated with the service and not directly with the IP rule. For more information on how service objects are used with IP rules, see Section 3.6, IP Rule Sets.
However, with an IP Policy object, the ALG options can be configured directly on the policy. The ALG options only become available on an IP policy when a service is associated with the policy that has its Protocol property set to the protocol for the ALG.
For convenience, a number of service objects are predefined in cOS Core. These include services for common protocols such as http and ftp.Predefined services can be used and also modified just like custom, user defined services. However, it is recommended to not make any changes to predefined services and instead create custom services with the desired characteristics.
Custom service creation is discussed in detail later in Section 3.3.2, Creating Custom Services.
Changes to Predefined Services in Version 11.01.00 and Later
With cOS Core version 11.01.00 and later, changes were made to the predefined Service objects. In 11.01.00 and later the following predefined services and the associated predefined ALGs were removed from a new cOS Core installation:
If a pre-11.01.00 configuration is upgraded to 11.01.00 or later, these predefined objects will continue to exist as before and can be used as before so there will be no change.
In a new installation of cOS Core 11.01.00 or later, these removed services and ALGs can be recreated as custom services and ALGs if desired but a better option is to use an IP Policy object. For example, the predefined http service can be used with an IP Policy and all of the settings that were previously available through the ALG are now available directly on the policy.
In a new installation of 11.01.00 or later, any of the following Service objects can be used directly with an IP Policy object in this way, removing the need to use a separate ALG:
With all of the above services, the settings of their corresponding ALG will become available on an IP Policy object they are associated with.
In the case of an upgrade from version of cOS Core prior to 11.01, the administrator can create these new versions of services by simply setting the Protocol property of the Service object to the correct value. The service can then be used with an IP policy as though it was a new installation of cOS Core.
This topic is also discussed in Section 6.1, ALGs.
Example 3.16. Listing the Available Services
To example shows how to produce a listing of all currently available services in cOS Core:
Command-Line Interface
Device:/> show ServiceServiceGroup
Name Comments
------------ --------------------------------------------------
all_services All ICMP, TCP and UDP services
all_tcpudp All TCP and UDP services
ipsec-suite The IPsec+IKE suite
l2tp-ipsec L2TP using IPsec for encryption and authentication
l2tp-raw L2TP control and transport, unencrypted
pptp-suite PPTP control and transport
ServiceICMP
Name Comments
------------ --------------------------------------------------
all_icmp All ICMP services
"
"InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.17. Viewing a Specific Service
This example shows how to view the properties of the echo system:
Command-Line Interface
Device:/> show Service ServiceTCPUDP echo Property Value
----------------- ----------------
Name: echo
DestinationPorts: 7
Type: TCPUDP (TCP/UDP)
SourcePorts: 0-65535
PassICMPReturn: No
ALG: <empty>
MaxSessions: 1000
Comments: Echo serviceInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
If the list of predefined cOS Core service objects does not meet the requirements for certain traffic then a new service can be created. Reading this section will explain not only how new services are created but also provides an understanding of the properties of predefined services.
The Type of service created can be one of the following:
TCP/UDP Service
A service based on the UDP or TCP protocol or both. This type of service is discussed further in this section.
ICMP Service
A service based on the ICMP protocol. This is discussed further in Section 3.3.3, ICMP Services.
IP Protocol Service
A service based on a user defined protocol. This is discussed further in Section 3.3.4, Custom IP Protocol Services.
Service Group
A service group consisting of a number of services. This is discussed further in Section 3.3.5, Service Groups.
TCP and UDP Based Services
Most applications use TCP and/or UDP as transport protocol for transferring data over IP networks.Transmission Control Protocol (TCP) is a connection-oriented protocol that includes mechanisms for reliable point to point transmission of data. TCP is used by many common applications where error-free transfers are mandatory, such as HTTP, FTP and SMTP.
An example TCP based protocol that will require a custom service object to be created is the Border Gateway Protocol (BGP). This uses TCP port number 179. Configuring cOS Core to allow BGP servers located on different Ethernet interfaces to communicate across a firewall is discussed in a Clavister Knowledge Base article at the following link:
https://kb.clavister.com/324735763
UDP Oriented Applications
For applications where data delivery speed is of greatest importance, for example with streaming audio and video, the User Datagram Protocol (UDP) is the preferred protocol. UDP is connectionless, provides minimal transmission error recovery, and has a much lower overhead when compared with TCP. Due to the lower overhead, UDP is also used for some non-streaming services and in those cases the applications themselves must provide any error recovery mechanisms.TCP and UDP Service Definition
To define a TCP or UDP based protocol to cOS Core, a TCP/UDP service object is used. Apart from a unique name describing the service, the object contains information about what protocol (TCP, UDP or both) and what source and destination ports are applicable for the service.Specifying Port Numbers
Port numbers are specified with all types of services and it is useful to understand how these can be entered in user interfaces. They can be specified for both the Source Port and/or the Destination Port of a service in one of the following ways:Single Port
For many services, a single destination port is sufficient. For example, HTTP usually uses destination port 80. The SMTP protocol uses port 25 and so on. For these types of service, the single port number is simply specified in the service definition as a single number.
Port Ranges
Some services use a range of destination ports. As an example, the NetBIOS protocol used by Microsoft Windows™ uses destination ports 137 to 139.
To define a range of ports in a TCP/UDP service object, the format mmm-nnn is used. A port range is inclusive, meaning that a range specified as 137-139 covers ports 137, 138 and 139.
Multiple Ports and Port Ranges
Multiple ranges or individual ports may also be entered, separated by commas. This provides the ability to cover a wide range of ports using only a single TCP/UDP service object.
For example, all Microsoft Windows networking can be covered using a port definition specified as 135-139,445. HTTP and HTTPS can be covered by specifying destination ports 80,443.
![[Tip]](images/tip.png) |
Tip: Specifying source ports |
|---|---|
|
It is usual with many services that the source ports are left as their default value which is the range 0-65535 (corresponding to all possible source ports). With certain application, it can be useful to also specify the source port if this is always within a limited range of values. Making the service definition as narrow as possible is the recommended approach. |
Other Service Properties
Apart from the basic protocol and port information, TCP/UDP service objects also have several other properties:If an attempt to open a TCP connection is made by a user application behind the firewall and the remote server is not in operation, an ICMP error message is returned as the response. Such ICMP messages are interpreted by cOS Core as new connections and will be dropped unless an IP rule explicitly allows them.
The Allow ICMP errors for active connections property allows such ICMP messages to be automatically passed back to the requesting application. In some cases, it is useful that the ICMP messages are not dropped. For example, if an ICMP quench message is sent to reduce the rate of traffic flow. On the other hand, dropping ICMP messages increases security by preventing them being used as a means of attack.
Enable IPv4 Path MTU Discovery
This can be enabled only if the Allow ICMP Errors property is enabled and permits the relaying of path MTU discovery ICMP messages. This feature is discussed further in Section 3.3.7, Path MTU Discovery.
This option allows a TCP based service to be configured with protection against SYN Flood attacks. This option only exists for the TCP/IP service type.
For more details on how this feature works see Section 7.4.3.6, TCP SYN Flood Attacks.
![[Caution]](images/caution.png) |
Caution: SYN flood protection may impact performance |
|---|---|
|
Note that enabling this option may impact traffic throughput. This is because various TCP optimizations will be disabled, including:
|
ALG
A TCP/UDP service can be linked to an Application Layer Gateway (ALG) to enable deeper inspection of certain protocols. This is the way that an ALG is associated with an IP Rule object. First, associate the ALG with a service and then associate the service with the IP Rule. However, it is easier to use an IP Policy instead where the ALG can be configured directly on the policy.
For more information on this topic see Section 6.1, ALGs.
An important property associated with a service is Max Sessions. This is given a default value when the service is associated with an ALG. The default value varies according to the protocol. If the default is, for example 100, this would mean that only 100 connections are allowed in total for this service across all interfaces.
For a service involving, for example, an HTTP ALG the default value can often be too low if there are large numbers of clients connecting through the firewall. It is therefore recommended to consider if a higher value is required for a particular scenario. Setting the correct value is discussed further in Section 6.1, ALGs.
Note that the Max Sessions setting has two values in a service. One value is for the service when used with an IP Rule. The other is for when the service is used with an IP Policy (and the Protocol property is therefore also set).
If, for example, the requirement is only to filter using the principal protocols of TCP, UDP and ICMP then the service group all_tcpudpicmp can be used instead.
|
Tip: The http-all service does not include DNS |
|---|---|
|
A common mistake is to assume that the predefined service http-all includes the DNS protocol. It does not so the predefined service dns-all is usually also required for most web surfing. This could be included in a group with http-all and then associated with the IP rule set entries that allow web surfing. |
Restrict Services to the Minimum Necessary
When choosing a Service object for a rule in the cOS Core configuration, the protocols included in that object should be as few as necessary to achieve the traffic filtering objective. Using the all_services object may be convenient but removes the security benefits that a more specific service object could provide.The best approach is to narrow the service filter in a security policy so it allows only the protocols that are absolutely necessary. The all_tcpudpicmp service object is often a first choice for general traffic but even this may allow many more protocols than are normally necessary and the administrator can often narrow the range of allowed protocols further.
Example 3.18. Creating a Custom TCP/UDP Service
This example shows how to add a TCP/UDP service, using destination port 3306, which is used by MySQL:
Command-Line Interface
Device:/> add Service ServiceTCPUDP MySQL
DestinationPorts=3306
Type=TCPInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Another type of custom service that can be created is an ICMP Service.
The Internet Control Message Protocol (ICMP) is a protocol that is integrated with IP for error reporting and transmitting control information. For example, the ICMP Ping feature uses ICMP to test Internet connectivity.
ICMP Types and Codes
ICMP messages are delivered in IP packets, and includes a Message Type that specifies the format of the ICMP message and a Code that is used to further qualify the message. For example, the message type Destination Unreachable uses the Code parameter to specify the exact reason for the error.Either all ICMP message types can be accepted by a service (there are 256 possible types) or it is possible to filter the types.
Specifying Codes
If a type is selected then the codes for that type can be specified in the same way that port numbers are specified. For example, if the Destination Unreachable type is selected with the comma delimited code list 0,1,2,3 then this will filter Network unreachable, Host unreachable, Protocol unreachable and Port unreachable.When a message type is selected but no code values are given then all codes for that type is assumed.
ICMP Message Types
The message types that can be selected are as follows:The source is told that a problem has occurred when delivering a packet. There are codes from 0 to 5 for this type:
The source is told that there is a better route for a particular packet. The codes assigned are as follows:
Services that run over IP and perform application/transport layer functions can be uniquely identified by IP protocol numbers. IP can carry data for a number of different protocols.
These protocols are each identified by a unique IP protocol number specified in a field of the IP header. For example, ICMP, IGMP and EGP have protocol numbers 1, 2 and 8 respectively.
Similar to the TCP/UDP port ranges described previously, a range of IP protocol numbers can be used to specify multiple applications for one service. For example, specifying the range 1-4,7 will match the protocols ICMP, IGMP, GGP, IP-in-IP and CBT.
IP protocol numbers
The currently assigned IP protocol numbers and references are published by the Internet Assigned Numbers Authority (IANA) and can be found at:Example 3.19. Adding an IP Protocol Service
This example shows how to create an IP Protocol service for the Virtual Router Redundancy Protocol (VRRP).
Command-Line Interface
Device:/> add Service ServiceIPProto VRRP IPProto=112InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A Service Group is a configuration object that consists of a collection of services. References to the group in the configuration are equivalent to referencing the addition of all the components services in the group. Although the group concept is simple, it can be very useful when constructing security policies.
The Advantage of Groups
For example, there may be a need for a set of IP rule set entries that are identical to each other except for the service parameter. By defining a service group which contains all the service objects from all the individual rules, we can replace all of them with just one IP rule set entry that uses the group.Suppose that we create a service group called email-services which combines the three services objects for SMTP, POP3 and IMAP. Now, only one IP rule set entry needs to be defined which uses this group service to allow all email related traffic to flow.
Groups Can Contain Other Groups
When a group is defined then it can contain individual services and/or service groups. This ability to have groups within groups should be used with caution since it can increase the complexity of a configuration and decrease the ability to troubleshoot problems.Example 3.20. Creating a Service
This example shows how to create a Service Group object called my_service_group which consists of two existing services called my_first_service and my_second_service.
Command-Line Interface
Device:/> add Service ServiceGroup my_service_group
Members=my_first_service,my_second_serviceInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Any service can have custom timeouts set for the lifetime values of connections. These can also be set globally in cOS Core but it is more usual to change these values individually on a custom service.
The timeout settings that can be customized are as follows:
Initial Idle Lifetime
This is the time in seconds allowed for a new connection to be open. The value specified must be greater than zero. The default value is 60 seconds.
Establish Idle Lifetime
If there is no activity on a connection for this number of seconds then it is considered to be closed and is removed from the cOS Core state table. The value specified must be greater than zero. The default setting for this timeout is 262,144 seconds (3 days).
The is the time in seconds allowed for the connection to be closed. The default value is 80 seconds but this may be too high in some scenarios.
From cOS Core version 14.00.06 this setting can take a value of zero, in which case the connection will be immediately queued for closure when a TCP RST or FIN packet is received.
This can be a helpful in some scenarios where connections need to be closed quickly because of high traffic loading or the behavior of certain external equipment. For example, external devices or hosts might attempt to reuse TCP source ports quickly. TCP connections are properly terminated but a new TCP SYN packet is sent to the same port before a non-zero Closing Idle Lifetime value has expired for that port. This issue could be resolved by setting Closing Idle Lifetime to zero.
Using this option is also discussed in a Clavister Knowledge Base article at the following link:
The administrator must make a judgment about what the acceptable values should be for a particular protocol. This may depend, for example, on the expected responsiveness of the external servers to which protected clients connect.
Overview
Path MTU Discovery (also shortened to just MTU discovery in this section) is a method by which the MTU size of either IPv4 or IPv6 packets sent across the Internet can be adjusted to meet the MTU limits of traversed network equipment and thus avoiding the need for fragmentation. When a packet exceeds a piece of network equipment's next-hop MTU limit and the packet's DF (Don't Fragment) flag is set, ICMP messages are sent back to the sender of the packet to resend with an adjusted MTU size. This is defined by RFC-1191 (for IPv4) and RFC-1981 (for IPv6).Implementation in cOS Core
The cOS Core path MTU discovery implementation allows both of the following two functions:The ICMP messages involved in MTU discovery between two external pieces of network equipment can be forwarded.
cOS Core will send MTU discovery ICMP messages back to the sender if the DF (Don't Fragment) flag is set and the packet size is larger than the MTU set for cOS Core's outgoing interface (the next-hop MTU).
The Clavister firewall cannot act as the endpoint in an MTU discovery message exchange. cOS Core will only forward ICMP messages or generate messages indicating the acceptable MTU of its own outgoing interface.
Path MTU discovery is always enabled by default for IPv6 on all cOS Core interfaces and will not be discussed further in this section. For IPv4, it must be enabled as described next.
Enabling IPv4 MTU Discovery on a Service Object
MTU discovery is not enabled for IPv4 by default. Instead, it must be explicitly enabled on the Service object associated with the IP rule set entry that allows the connection. This is done by enabling the following two properties of the Service object:Forward ICMP Errors
Enable IPv4 Path MTU Discovery
The second property can only be enabled after the first property is enabled. The IP rule set entry with which the service is used can be of any type except a Stateless Policy (or FwdFast IP rule).
To illustrate a typical path MTU discovery message exchange, consider a client computer trying to connect to a server via a Clavister firewall and the Internet as well as via a router. This is shown in the diagram below.Assuming that MTU discovery has been enabled on the relevant IP rule set entry, the following sequence of events illustrates how MTU discovery functions:
The client tries to open a connection to the server via the firewall using a packet size of 1400 bytes. The packets sent have the DF (Don't Fragment) flag enabled.
cOS Core looks at the MTU property value for the interface object used for the next hop. This is 1300 so the client's packet MTU is too high and fragmentation cannot be performed.
cOS Core sends an ICMP message to the client to indicate that fragmentation is needed and the acceptable MTU for the next hop is 1300 or less.
The client now resends the packet with the requested 1300 size and this is forwarded by cOS Core towards the server.
The router in front of the server sends back an ICMP message to cOS Core to indicate that the packet size is too big and an MTU size of 1000 or less is acceptable.
cOS Core forwards this ICMP message to the client.
The client now resends again using a packet size of 1000 which is acceptable to both the firewall and the router so the server is now accessible.
Disabling the DF flag means that path MTU discovery will not be used for that packet and it therefore becomes a possibility that a packet above the acceptable MTU size of network equipment will be fragmented. In most cases, this will only cause a degradation in performance.
However, explicitly enabling path MTU discovery on a Service object will override the Strip Don't Fragment setting and so it does not need to be changed for MTU discovery.
Enabling path MTU discovery in cOS Core is further discussed in an article in the Clavister Knowledge Base which can be found at the following link:
https://kb.clavister.com/324735757
It is also discussed in another Knowledge Base article about general MTU troubleshooting at the following link:
https://kb.clavister.com/324736206
Example 3.21. Enabling Path MTU Discovery on an IP Policy
This example shows how to set up path MTU discovery for an IP Policy that already exists called int_to_ext_http. The rule NATs internal clients to the Internet. The clients are surfing the Internet so a Service object called my_http_pmd_service will be created which has path MTU discovery enabled and this will be associated with the IP Policy.
Command-Line Interface
First, create a service object:
![[Note]](images/note.png)
Device:/> add Service ServiceTCPUDP my_http_pmd_service
Type=TCP
DestinationPorts=80,443
PassICMPReturn=Yes
AllowIPv4PathMTUDiscovery=Yes
Next, modify the IP policy to use the new service.
Device:/> set IPPolicy int_to_ext_http Service=my_http_pmd_service
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First, create a new service object:
Next, modify the IP policy to use the new service:
