Network Access Control Rules with CMAN

Controlling access to your database server through CMAN takes the same two part pattern as the previous lesson's session multiplexing feature: configure the rules in cman.ora, and route the client connections you want governed by those rules through CMAN rather than straight to the database. Once those rules are in place, CMAN follows a simple, strict principle: that which is not expressly permitted is prohibited. A connection that does not match an accepting rule does not get through, full stop.

The RULE Parameter

Access control rules live in the cman.ora file's RULE_LIST, as introduced in the third lesson of this module, with each RULE built from four fields:

• SRC, the source host name, IP address, or subnet of the client
• DST, the destination host name or IP address of the database server
• SRV, the database service name, taken from the SERVICE_NAME parameter in the database's initialization parameter file, not the SID
• ACT, the action: accept to allow the connection, reject to refuse it, or drop to refuse it silently, without sending the client an error message

CMAN does not support wildcards for partial IP addresses; a wildcard has to replace a full address, for example (SRC=*) for any client. Subnets use /nn notation only, for example 192.0.2.32/27 for a subnet defined by the 27 left most bits.

Example

The rule list below rejects one client outright, accepts a specific client and server pair, and grants CMAN's own administrative service, cmon, the access it needs to communicate with CMCTL:

(RULE_LIST=
  (RULE=(SRC=client1-pc)(DST=sales-server)(SRV=sales.us.example.com)(ACT=reject))
  (RULE=(SRC=192.0.2.45)(DST=192.0.2.200)(SRV=db1)(ACT=accept))
  (RULE=(SRC=sale-rep)(DST=sales1-server)(SRV=cmon)(ACT=accept)))

A fuller cman.ora file, combining this rule list with the listening address and parameter list covered in the fourth lesson of this module, would wrap it like this:

CMAN=
  (CONFIGURATION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=proxysvr)(PORT=1521))
    (RULE_LIST=
      (RULE=(SRC=client1-pc)(DST=sales-server)(SRV=sales.us.example.com)(ACT=reject))
      (RULE=(SRC=192.0.2.45)(DST=192.0.2.200)(SRV=db1)(ACT=accept))
      (RULE=(SRC=sale-rep)(DST=sales1-server)(SRV=cmon)(ACT=accept)))
    (PARAMETER_LIST=(MAX_GATEWAY_PROCESSES=8)(MIN_GATEWAY_PROCESSES=3)))

Rule Matching Behavior

Multiple rules can be defined in one RULE_LIST, and CMAN applies the action from the first rule that matches a given connection request, not every rule that matches; once a request matches, CMAN stops evaluating and does not keep checking the rest of the list. If no rules are specified at all, every connection is rejected, which is the same default deny principle stated above, just enforced by the absence of any rule rather than by an explicit one.

This is also why cmon needs its own rule. There must be at least one rule covering ordinary client connections and one covering CMCTL connections, and omitting either means every connection of that type is rejected, not just the unmatched ones. A RULE_LIST that only covers client traffic and forgets a cmon rule will quietly lock CMCTL itself out of the instance it is supposed to administer.

Walking through the example above makes the first match behavior concrete. A connection from client1-pc to sales-server asking for the sales.us.example.com service matches the first rule and is rejected; CMAN never evaluates the second or third rule for that request, because a match was already found. A connection from 192.0.2.45 to 192.0.2.200 asking for service db1 skips the first rule entirely, since neither the source nor the service matches, and is accepted by the second rule. A CMCTL command directed at the instance matches the third rule by virtue of requesting the cmon service, and is accepted. Any connection that does not match any of the three, say a different client asking for a different service, falls through the entire list and is rejected by the default deny behavior described above.

Rule-Level Overrides

A rule can also carry its own ACTION_LIST, overriding CMAN's global settings just for that rule:

• AUT, which controls Oracle Database security authentication on the client side
• CONN_STATS, which logs input and output statistics for connections matching the rule
• MCT, the maximum connect time for a matching connection
• MIT, the maximum idle timeout for a matching connection
• MOCT, the maximum outbound connect time for a matching connection

These rule-level settings override CMAN's global parameter list settings, but only for connections that match that particular rule, which makes ACTION_LIST a useful way to apply a stricter idle timeout or connect time limit to one sensitive service without changing the limits for every other connection CMAN handles. Attached to a rule, it looks like this:

(RULE=
  (SRC=192.0.2.45)
  (DST=192.0.2.200)
  (SRV=db1)
  (ACT=accept)
  (ACTION_LIST=AUT=on((CONN_STATS=yes)(MCT=3600)(MIT=600)(MOCT=120))))

That one rule accepts connections from 192.0.2.45 to db1, requires Oracle Database security authentication on the client side, logs connection statistics, and caps the connection at a one hour maximum connect time, a ten minute idle timeout, and a two minute maximum outbound connect time, all without touching any other rule in the list.

Applying Rule Changes

Changing RULE_LIST does not require taking CMAN down. The CMCTL RELOAD command dynamically rereads both parameters and rules while CMAN keeps running, which is the normal way to apply a rule change in production rather than restarting the instance and dropping every connection currently going through it.

A Related Feature: IP Rate Limiting

Access control through RULE_LIST filters connections by who is asking and what they are asking for; a separate, newer set of parameters filters by how fast they are asking. IP_RATE_COUNT, set in the parameter list, caps the number of connections CMAN accepts from a single IP address within a time window:

CMAN=
  (CONFIGURATION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=proxysvr)(PORT=1521))
    (PARAMETER_LIST=(IP_RATE_COUNT=512)))

Two optional companions refine that limit further: IP_RATE_INTERVAL sets the window's length in seconds, up to a maximum of 60 and defaulting to just 1 second, and IP_RATE_BLOCK sets how long, in minutes, an address that exceeds the limit stays blocked, defaulting to 15 minutes. This is the IP rate limiting feature mentioned as a 26ai addition in the first lesson of this module, aimed at denial of service protection rather than ordinary access control; a client can be perfectly entitled to connect under your RULE_LIST and still get throttled here if it opens connections too quickly.

One more thing worth settling before you put any of this into practice: using CMAN's features at all does not depend on a particular naming method the way some older material suggests. Earlier versions of this course instructed readers to verify they were using "either centralized naming using Oracle Names or local naming." Oracle Names was desupported in Oracle Database 10g, as covered repeatedly earlier in this module, and it does not appear among the naming methods Oracle currently documents, which are local naming, directory naming, the centralized configuration provider method, and Easy Connect; see our guide to modern Oracle connection methods for where Oracle Names' role has gone since. Whichever current naming method your environment uses, CMAN's access control rules work the same way: by host, service name, and the action you assign.

Designing a Rule Set

Because CMAN stops at the first match, the order rules appear in matters as much as their content. A narrow, specific rule placed after a broad one that already matches the same traffic will never fire, since the broad rule claims the connection first. The practical pattern that follows from this is to put your most specific rules, the ones naming exact clients, exact services, or tight exceptions, near the top of the list, and leave broader catch all rules, including an explicit reject or drop for everything else, toward the bottom. Combined with the fact that an empty rule list already rejects everything, a well ordered RULE_LIST rarely needs an explicit final catch all rule at all, though adding one, and documenting why it is there, still makes the intended behavior easier for the next administrator to follow.

The next lesson outlines how to use CMCTL to start and control Oracle Connection Manager, building directly on the rules configured here.