| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The cOS Core Address Book contains named objects representing various types of IP addresses, including single IP addresses, networks as well as ranges of IP addresses. Ethernet MAC addresses can also be defined in the address book.
Using address book objects has a number of important benefits:
It increases understanding of the configuration by using meaningful symbolic names.
Using address object names instead of entering numerical addresses reduces errors.
By defining an IP address object just once in the address book, changing the definition automatically also changes all references to it.
IP Address objects are used to define symbolic names for IPv4 and IPv6 addresses. An address object can represent either a single IP address (a specific host), a network or a range of IP addresses.
IP Address objects can additionally be used for specifying the credentials used in user authentication. For more information about this topic, see Chapter 9, User Authentication.
An address object for a simple IP address can be one of two types:
An IP4 Address object for IPv4 addresses.
An IP6 Address object for IPv6 addresses.
This section now goes on to describe the various ways that an IP4 Address object can be used. IP6 Address objects are described further in Section 3.2, IPv6 Support.
IPv4 Address Types
The following list presents the various types of addresses an IP4 Address object can hold, along with what format is used to represent that specific type:Host
A single host is represented simply by its IP address. For example, 192.168.0.14.
IP Network
An IP Network is represented using Classless Inter Domain Routing (CIDR) form. CIDR uses a forward slash and a digit (0-32) to denote the size of the network as a postfix. This is also known as the netmask.
/24 corresponds to a class C net with 256 addresses (netmask 255.255.255.0), /27 corresponds to a 32 address net (netmask 255.255.255.224) and so on.
The numbers 0-32 correspond to the number of binary ones in the netmask. For example: 192.168.0.0/24.
IP Range
A range of IPv4 addresses is represented with the form a.b.c.d - e.f.g.h.
Note that ranges are not limited to netmask boundaries. They may include any span of IP addresses. For example, 192.168.0.10-192.168.0.15 represents six hosts in consecutive order.
Using a /31 Subnet Mask (RFC-3021)
It is possible to use an IPv4 31 bit subnet prefix (as defined in RFC-3021) in the cOS Core address book but some special considerations are required, otherwise this may be rejected by cOS Core. This topic is discussed further in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324735678
Example 3.1. Adding a Simple IP4 Address
This example adds the IPv4 host wwwsrv1 with IP address 192.168.10.16 to the address book:
Command-Line Interface
Device:/> add Address IP4Address wwwsrv1 Address=192.168.10.16InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.2. Adding an IPv4 Network
This example adds an IPv4 network named wwwsrvnet with address 192.168.10.0/24 to the address book:
Command-Line Interface
Device:/> add Address IP4Address wwwsrvnet Address=192.168.10.0/24InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.3. Adding an IPv4 Range
This example adds a range of IPv4 addresses from 192.168.10.16 to 192.168.10.21 and names the address object wwwservers:
Command-Line Interface
Device:/> add Address IP4Address wwwservers
Address=192.168.10.16-192.168.10.21InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.4. Deleting an Address Object
To delete an object named wwwsrv1 in the address book, do the following:
Command-Line Interface
Device:/> delete Address IP4Address wwwsrv1InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Deleting In-use IP Objects
If an IP object is deleted that is in use by another object then cOS Core will not allow the configuration to be deployed and will generate a warning message. In other words, it will appear that the object has been successfully deleted but cOS Core will not allow the configuration to be saved to the firewall.Ethernet Address objects are used to define symbolic names for MAC addresses. This is useful, for example, when populating the ARP table with static ARP entries or for other parts of the configuration where symbolic names are preferred over numerical Ethernet addresses.
When specifying an Ethernet address the format aa-bb-cc-dd-ee-ff should be used. Ethernet addresses are also displayed using this format.
Identifying the Related Hardware Manufacturer
A MAC address can be used for identifying the manufacturer of the related hardware and this is covered further in a Clavister Knowledge Base article at the following link:https://kb.clavister.com/309987726
The cOS Core Device Intelligence feature provides the ability to identify information about external devices from their MAC addresses. This feature is fully described in Section 3.5.6, Device Intelligence.
Example 3.5. Adding an Ethernet Address
The following example adds an Ethernet Address object named wwwsrv1_mac with the numerical MAC address 08-a3-67-bc-2e-f2.
Command-Line Interface
Device:/> add Address EthernetAddress wwwsrv1_mac
Address=08-a3-67-bc-2e-f2InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Groups Simplify Configuration
Address objects can be grouped together in order to simplify configuration. Consider a number of public servers that should be accessible from the Internet. The servers have IP addresses that are not in a sequence, and can therefore not be referenced as an IP range. Consequently, individual IP Address objects have to be created for each server.Instead of having to cope with the burden of creating and maintaining separate security policies that allow traffic to each server, an Address Group, for example called web-servers, could be created with the web server hosts as group members. Now, a single IP rule set entry can use the group as part of its filtering criteria, greatly simplifying the administrative task.
Address Group Types
An address group object can be one of the following types:An IP4 Group object - This can contain only IPv4 Address objects as members.
An IP6 Group object - This can contain only IPv6 Address objects as members.
An Ethernet Address Group object - This can contain only Ethernet Address objects as members.
An FQDN Group object - This can contain only FQDN Address objects as members.
Group Membership Can Mean Inclusion or Exclusion
When groups are created with the Web Interface or InControl, it is possible to not only add address objects but also to explicitly exclude addresses from a group. However, it should be noted that excluding addresses from a group is not possible when manipulating groups using the CLI.Exclusion from a group should not be confused with removing a member of a group. The excluded address object is still a member of a group but its effect on the group is to subtract from the IP address space described by the group.
For example, if a group member has the value 192.168.2.0/24, the single IPv4 address 192.168.2.1 could be an excluding member of the group. This will result in the group being equivalent to the range 192.168.2.2 to 192.168.2.255.
Groups Can Contain Different Subtypes
Although groups must contain the same type of object (for example, IP4 addresses), it is possible to mix subtypes in a group. For example, single IPv4 addresses can be combined with IPv4 ranges and IPv4 networks in an IP4 Group. The group will represent a union of all the member object's addresses.For example, suppose an IP4 Group contains two member IP4 Address objects with the following IP address ranges:
The union represented by this group will be an address range of 192.168.0.10 - 192.168.0.19.
Adding and Removing Group Members Using the CLI
Once a group is established, it is often useful to be able to add new members or remove existing members. This is easily done with the Web Interface which provides an intuitive display showing the available objects and the objects in the group. It can also be done with the CLI but requires a special command syntax.Suppose there already exists an IP4Group object called my_ip_group. It has three member IP4Address objects called my_ip_1, my_ip_2 and my_ip_3. Suppose that the object my_ip_2 is to be removed from the group. The command would be:
Device:/> set Address IP4Group my_ip_group Members-=my_ip_2The option Members-= can remove one or more members of the group. To add one or more members to a group, the option Members+= can be used. Suppose that the IP4Address objects my_ip_4 and my_ip_5 are to be added to the group. The command would be:
Device:/> set Address IP4Group my_ip4_group Members+=my_ip_4,my_ip_5
Example 3.6. Creating an IP4 Group Object
This example assumes that two IP4 Address objects already exist in the address book and these are called my_ip4_address1 and my_ip4_address2. These addresses are to be combined into a single IP4 Group called my_ip4_group.
Command-Line Interface
Device:/> add Address IP4Group my_ip4_group
Members=my_ip4_address1,my_ip4_address2InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
To simplify the configuration, a number of address objects in the address book are automatically created by cOS Core when the system starts for the first time and these objects are used in various parts of the initial configuration.
The following address objects are auto-generated:
Interface Addresses
For each Ethernet interface in the system, two IP Address objects are predefined; one object for the IPv4 address of the actual interface, and one object representing the local network for that interface.
Interface IPv4 address objects are named <interface-name>_ip and network objects are named <interface-name>_net. As an example, an interface named If1 will have an associated interface IP object named If1_ip, and a network object named If1_net.
These addresses are stored in an address book folder called InterfaceAddresses. However, in virtualized configurations, these addresses will be top level address book entries.
On some older Clavister hardware models, the underscore is left out from the auto-generated interface network name. For example, the lan interface will have the network object lan_net.
When changing the IP address of an Ethernet interface, it is strongly recommended to change the address of the default address book object and not change the IP address directly on the Ethernet interface.
The Default Gateway Address
On most cOS Core hardware platforms, an IPv4 Address object with the suffix "_gw" is also auto-generated for the default interface used for connection to the Internet. For example, if the Internet connection is assumed to be on interface wan then the default gateway address gets the name wan_gw. This IP address represents the external router which acts as the gateway to the Internet.
This address is used primarily by the routing table, but is also used by the DHCP client subsystem to store gateway address information acquired through DHCP. The object will have an empty IP address (0.0.0.0/0), and the correct IP address for the default gateway needs to be defined unless DHCP is being used and assigns it automatically.
The all-nets Address Object
The all-nets IP address object is initialized to the IPv4 address 0.0.0.0/0, which represents all possible IPv4 addresses. The all-nets IP object is used extensively when configuring of cOS Core and it is important to understand its significance.
In order to help organize large numbers of entries in the address book, it is possible to create one or more Address Folder objects in the address book. These act like a folder in a computer's file system. They are created with a given name and can be used to gather together related address objects.
Using folders is simply a way for the administrator to conveniently divide up address book entries and no special properties are given to entries in different folders. cOS Core continues to see all entries as though they were in a large table of IP address objects.
The folder concept is also used by cOS Core in other contexts such as IP rule sets, where related entries can be grouped together in administrator created folders.
As discussed previously, there will already be a default folder created on initial startup called InterfaceAddresses which contains the default address objects for all the Ethernet interfaces detected by cOS Core.
Example 3.7. Adding an Address Folder Object
This example adds a new Address Folder object called my_address_folder.
Command-Line Interface
Device:/> add Address AddressFolder my_address_folderInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Overview
Instead of specifying an address object to be an IP address, it can instead be specified as an FQDN (for example: server1.example.com) in an FQDN Address object. cOS Core will then automatically resolve the FQDN to an IP address when the object is referenced by other configuration objects.FQDN Address Object Properties
An FQDN Address object has the following properties:Name - The logical name of the object. This is specified by the administrator.
Address - The FQDN of the object. This is specified by the administrator.
Active Address - If the FQDN has been resolved then this will be the FQDN's IP address. Otherwise, this property has no value assigned to. This property can only be set by cOS Core.
Rules and Objects Supporting FQDN Address Object Usage
Currently, only the following types of cOS Core objects can contain a reference to an FQDN Address object.The source and/or destination networks of an IP Policy object.
Note that FQDN Address objects cannot be used with IP Rule objects.
The source and/or destination networks of Goto Rule or Return Rule objects in IP rule sets.
The source and/or destination networks of an IDP Rule object.
The source and/or destination networks of a Pipe Rule object used for traffic shaping.
The source and/or destination networks of a Threshold Rule object used for traffic rate limiting.
The IP address of a custom time server when configuring the system date and time.
FQDN Resolution Requires a Configured DNS Server
For FQDN Address objects to function correctly, at least one external DNS server must be configured by creating a DNS Server object. For a description of configuring DNS servers in cOS Core, see Section 3.10, DNSIt is also important that the DNS server that resolves FQDN addresses and the replies it sends back can be trusted. Trust in the server is usually only an issue when a private DNS server is being used. If a server is compromised or its replies can be faked then this could result in FQDN queries being resolved to the IP addresses of malicious websites.
DNS Lookups Should Be Consistent Across Hosts and Firewalls
The administrator should ensure that the DNS lookup used for FQDN Address objects referenced by IP Policy objects returns the same results as the DNS lookup used by hosts that are affected by those policies. The best way to do this is to ensure that cOS Core is using the same DNS server as the hosts it is protecting.FQDN Address Object Usage Triggers FQDN Resolution
cOS Core will try to perform the DNS resolution only when a new configuration is deployed and that configuration makes use of an FQDN Address object. In other words, an FQDN Address object might already be in the current cOS Core configuration but the DNS lookup will only be performed when the configuration is changed so that the address object is referred to by, for example, an IP Policy object.If no DNS server is configured, cOS Core will generate an error when attempting to deploy a configuration that makes use of an FQDN Address object in, for example, an IP Policy object.
Behavior With DNS Resolution Failure
If an FQDN Address object cannot be resolved to an IP address by cOS Core then any rules that reference the object will not be triggered by any traffic (in other words, it will appear as though the rules do not exist in the configuration).Similarly, an IPsec tunnel with an endpoint specified as an FQDN address object will fail to be established if the FQDN cannot be resolved. In addition, any Mail Alerting object will not send alerts if its FQDN address object cannot be resolved.
DNS Responses Can Contain Multiple IPs
Depending on the FQDN, the DNS lookup can return both IPv4 and IPv6 addresses and there can be multiple IPs of each type in a single DNS reply. When a DNS query returns multiple addresses in a single reply, any of the addresses may be assigned by cOS Core to the FQDN Address object that initiated the query.cOS Core can handle up to 1000 IPv4 addresses and/or 100 IPv6 addresses in a single DNS reply. Any IP addresses in excess of the 1000 limit for either type will be dropped. All addresses returned with a DNS reply will be stored in the FQDN cache so they can be looked up later.
Rule Processing Includes All FQDN IP Addresses
When cOS Core matches traffic against a rule that references an FQDN Address object, it checks against all the IP addresses associated with the FQDN. This means that if a DNS server returns more than one address in the same or multiple replies, the rule will trigger correctly for any of the IP addresses.This is not relevant when FQDN Address objects are used as a single endpoint. For example, with IPsec Tunnel or Mail Alerting objects.
cOS Core uses an internal FQDN address cache to ensure that the same FQDN Address object does not need to be resolved every time it is referenced. The current cache contents can be examined using the following CLI command:Device:/> dns -cacheDevice:/> dns -cache
Name Status IP Cnt Address
---------------------------------- ---------- ------ --------------------
my_fqdn_address1 Resolved 1 server1.example.com
my_fqdn_address2 Unused 0Device:/> dns -cache <FQDN>Device:/> dns -cache my_fqdn_address1
Address : my_fqdn_address1
Status : Resolved
IP address LifeTime
-------------------------------------------------- --------
203.0.113.3 299This information about the DNS cache can also be accessed in the Web Interface by going to Status > Run-time Information > DNS Cache.
When the DNS server returns IP addresses for an FQDN Address object, it also returns a Time To Live (TTL) value (also known as the lifetime). This value is stored with the entry for the FQDN Address object in the DNS cache. When the TTL expires, cOS Core will refresh the cache entry by issuing a new DNS query.The TTL returned from the DNS server could be very low or even zero. For this reason, cOS Core provides a global DNS setting called Minimum TTL with a default value of 1 second. The greater of the TTL value returned from a DNS server and the value of Minimum TTL will determine when cOS Core queries the DNS server again.
The Minimum Cache Time Setting
There is also a second global DNS setting called Minimum Cache Time which has a default value of 86,400 seconds (one day). cOS Core will only remove an entry from the cache before the Minimum Cache Time period expires if the cache is full when a new entry needs to be added.The Minimum Cache Time setting can be important when multiple DNS queries for the same FQDN might return different IP addresses. Some DNS servers may work in a round-robin fashion for a given FQDN, returning different IP addresses to consecutive queries to spread the server load. A higher minimum cache time can ensure all the possible IP addresses for a given FQDN will coexist in the cache.
Note that the TTL of a cache entry expires but the minimum cache time has not yet been reached, then a new DNS request for the FQDN will be issued by cOS Core and an additional cache entry will be created for any new IP address returned by the DNS server.
The asterisk "*" character can be used as a wildcard in the FQDN of an FQDN Address object to represent any combination of characters. The following rules apply to how wildcards can be used:The wildcard can only be used as the first and/or last character in an FQDN. For example, *.example.com and www.example.* are both valid, as is *.example.*. However, www.*.com is invalid and will be rejected by cOS Core.
As the first and/or last character, the wildcard can also be used to match a portion of the string. For example, *server.example.com would match client_server.example.com and vpn_server.example.com.
Wildcards can only be used when the FQDN Address object is part of a filter in the cOS Core configuration. For example, *.example.com could be the FQDN for the Destination Network property of an IP Policy object.
Wildcards cannot be used when the address object could only be a single IP address. For example, the IP address of a network time server could be specified as an FQDN Address object but the FQDN must not contain a wildcard.
When wildcards are used, a suitable DNS Profile object should be associated with the IP Policy that allows the DNS queries of the clients accessing the wildcarded websites. For wildcards to work, the Populate DNS cache property of the profile must be enabled (by default, it is). Setting up such a profile is described in Section 6.1.12, DNS ALG.
Configuring a DNS Profile is necessary so that the DNS cache is populated with entries from the DNS queries sent out to a DNS server from clients. The DNS ALG implemented with the DNS Profile object will mediate the DNS query process and place the multiple DNS responses generated by wildcards into the cache.
If a DNS Profile is not used, FQDN wildcards will not work.
![[Caution]](images/caution.png) |
Caution: Wildcard usage can consume system resources |
|---|---|
|
Excessive use of FQDN wildcards can consume resources which might impact system performance. |
A further discussion of FQDN wildcard usage can be found in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735784
cOS Core can generate the following log messages associated with FQDN Address objects:Example 3.8. Adding an FQDN Address Object
This example shows how an FQDN Address object called my_fqdn_address1 is added to the cOS Core address book.
The FQDN Address object will contain the address for the FQDN server.example.com. It is assumed that a least one DNS server is already configured in cOS Core so the FQDN can be resolved to an IP address.
Command-Line Interface
Device:/> add Address FQDNAddress my_fqdn_address1
Address=server.example.comInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.9. Setting the DNS Minimum TTL and Minimum Lifetime
This example sets the Minimum TTL value to 10 seconds and the Minimum Cache Time to 1000 seconds.
Command-Line Interface
Device:/> set DNS MinTTL=10 MinCacheTime=1000InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Example 3.10. Using FQDN Objects with an IP Policy
In this example, connections from internal clients on the lan_net network to the website www.example.com will not be allowed.
Command-Line Interface
A. Create the FQDN object for www.example.com:
Command-Line Interface
Device:/> add Address FQDNAddress example_website Address=www.example.comB. Drop connections to the site:
Device:/> add IPPolicy Name=deny_lan_to_example
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=any
DestinationNetwork=example_website
Service=all_services
Action=DenyInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create the FQDN object for www.example.com:
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
B. Drop connections to the site:
Normal IP address book objects can be gathered together into Address Group objects. In the same way, FQDN Address objects can be gathered together into FQDN Group objects. This means, for example, that multiple IP policies would not be needed when the same policy is to be applied using multiple FQDN Address objects. Instead, one policy can refer to an FQDN Group object.
![[Note]](images/note.png) |
Note: IP rules do not support FQDN groups |
|---|---|
|
Like FQDN Address objects, FQDN Group objects can be used with IP Policy objects but not IP Rule objects. |
As an example, consider three FQDN Address objects that refer to the FQDNs example.com, www.example.com and server.example.com. These three can be gathered into an FQDN Group object which can then be used by a single IP Policy object to allow connections to or from all three.
|
Note: FQDN groups cannot contain an FQDN group |
|---|---|
|
An FQDN Group object can only include FQDN Address objects. It cannot include another FQDN Group object. |
Example 3.11. Adding an FQDN Group Object
This example will create a new FQDN Group object called my_fqdn_group. The group will consist of the FQDN Address objects called my_fqdn_address1 and my_fqdn_address2.
Command-Line Interface
Device:/> add Address FQDNGroup my_fqdn_group
Members=my_fqdn_address1,my_fqdn_address2InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
