One of the principal functions of cOS Core is to allow only authorized connections access to protected data resources. Access control is primarily addressed by the cOS Core IP rule set in which a range of protected LAN addresses are treated as trusted hosts, and traffic flow from untrusted sources is restricted from entering trusted areas.

Before a new connection is checked against the IP rule set, cOS Core checks the connection source against the Access Rule entries in the Access Rule Set. Access rules can be used to specify what traffic source is expected on a given interface and also to automatically drop traffic originating from specific sources. Access rules provide an efficient and targeted initial filter for new connection attempts.

The Default Access Rule

Even if the administrator does not explicitly specify any custom access rules, an access rule is always in place which is known as the Default Access Rule.

This default rule is not really a true rule but operates by checking the validity of incoming traffic by performing a reverse lookup in the cOS Core routing tables. This lookup validates that the incoming traffic is coming from a source that the routing tables indicate is accessible via the interface on which the traffic arrived. If this reverse lookup fails then the connection is dropped and a Default Access Rule log message will be generated.

When troubleshooting dropped connections, the administrator should look out for Default Access Rule messages in the logs. The solution to the problem is to create a route for the interface where the connection arrives so that the route's destination network is the same as or contains the incoming connection's source IP.

The default access rule is discussed further in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735778

Custom Access Rules are Optional

For most configurations the default access rule is sufficient and the administrator does not need to explicitly specify other rules. The default rule can, for instance, protect against IP spoofing, which is described in the next section. If access rules are explicitly specified, then the default access rule is still applied if a new connection does not match any of the custom access rules.

The recommendation is to initially configure cOS Core without any custom access rules and add them if there is a requirement for stricter checking on new connections.

Traffic that pretends it comes from a trusted host can be sent by an attacker to try and get past cOS Core's security mechanisms. Such an attack is commonly known as Spoofing.

IP spoofing is one of the most common spoofing attacks. Trusted IP addresses are used to bypass filtering. The header of an IP packet indicating the source address of the packet is modified by the attacker to be a local host address. The firewall will believe the packet came from a trusted source. Although the packet source cannot be responded to correctly, there is the potential for unnecessary network congestion to be created and potentially a Denial of Service (DoS) condition could occur. Even if cOS Core is able to detect a DoS condition, it is hard to trace or stop because of its nature.

VPNs provide one means of avoiding spoofing but where a VPN is not an appropriate solution then access rules can provide an anti-spoofing capability by providing an extra filter for source address verification. An access rule can verify that packets arriving at a given interface do not have a source address which is associated with a network of another interface. In other words:

DOS attacks are discussed further in Section 7.4.3, DoS Attack Examples.

The configuration of an access rule is similar to other types of rules. Each rule has filtering properties to target specific traffic plus an action to take if the rule is triggered.

Access Rule Filtering Fields

The access rule filtering fields used to trigger a rule are the following:

Access Rule Actions

The access rule actions that can be specified are:

Turning Off Default Access Rule Messages

If, for some reason, the Default Access Rule log message is continuously being generated by some source and needs to be turned off, then the way to do this is to specify an access rule for that source with an action of Drop.

Troubleshooting Access Rule Related Problems

It should be noted that access rules are a first filter of traffic before any other cOS Core subsystems can see it. Sometimes problems can appear, such as setting up VPN tunnels, precisely because of this. It is always advisable to check the access rule set when troubleshooting puzzling problems in case a rule is preventing some other function, such as VPN tunnel establishment, from working properly.

Device:/> add Access Name=lan_Access
			Interface=lan
			Network=lan_net
			Action=Expect