You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

In this section:

 

System Created ACLs

System-created ACLs are configured to accept only incoming traffic. The

Unable to show "metadata-from": No such page "_space_variables"
installs a set of System defined ACL rules. These rules are statically defined and support ping, DNS, and different OAM traffic without any configuration.

System ACL rules filter the packets based on the source port (Client applications) or destination port (server applications) and protocol. Figure 1  gives a brief overview of a system-created ACL.

System-Created ACL

System Defined Rules

ACL read-only rules defined by the system to allow some of the known services:

  • Allow SSH traffic into the system, fill rate is 100 packets/sec
  • Allow SFTP traffic into the system, fill rate is 12,500 packets/sec
  • Allow HTTP traffic into the system, fill rate is 100 packets/sec
  • Allow HTTPS traffic into the system, fill rate is 12,500 packets/sec
  • Allow SNMP traffic into the system, fill rate is 50 packets/sec
  • Allow DNS traffic into the system, fill rate is 600 packets/sec
  • Allow Radius authentication traffic into the system, fill rate is 4 packets/sec
  • Allow Radius Accounting traffic into the system, fill rate is 1200 packets/sec
  • Allow NTP traffic into the system, fill rate is 4 packets/sec
  • Allow SNMP Trap traffic into the system, fill rate is 10 packets/sec
  • Allow ICMPv4 traffic into the system, fill rate is 50 packets/sec
  • Allow ICMPv6 traffic into the system, fill rate is 400 packets/sec

Accept Rules

Accept rules can optionally specify packet policings. If so configured, packets matching these rules are only accepted up to the configured policing limits.

Default Rules

Default rules are read-only and defined by the system to allow access to some of the known services. Default rules can be overridden by the operator defined rules.

SBC installs a set of approximately 15 System OAM ACL (band-4 ACLs) rules at boot time. These rules are statically defined at compile time and serve to permit OAM traffic over the default management interface group with no customer configuration effort. The system installs additional call signaling-specific (for example SIP Unknown Peer) ACL rules dynamically whenever signaling ports are enabled. ACL rule keys include:

  • Address Context ID
  • Interface Group ID
  • Interface ID
  • IP source address and prefix-length, v4 or v6
  • IP destination address and prefix-length, v4 or v6
  • IPv4 Protocol field or IPv6 Next Header field
  • TCP/UDP source port
  • TCP/UDP destination port

This strategy allows for more dynamic System Default rules which are driven by the specific configuration of the system for better protection (rules more tightly tailored to the actual traffic expected) and reduces the amount of user effort required to provision and operate the system.

Operator Created ACLs

An operator-created ACL has higher priority therefore can override any system-created rule for a given packet.

Each operator-created ACL rule is given a unique precedence and if a packet does not match the rule, it is denied entrance into 

Unable to show "metadata-from": No such page "_space_variables"
server. Figure 2  gives a brief overview of operator created ACL policing.

Operator-Created ACL

Operator Provisioned Rules

Operator-defined accept or discard rules apply to all incoming packets and are provisioned using the CLI or EMA. Operator created ACL filter rules are configured to permit or deny access based on:

  • Protocol
  • Source IP Address
  • Destination IP Address
  • Next Layer Protocol
  • Source Port Number
  • Ingress IP Interface
  • Interface Group Destination Port Number

Before creating operator-provisioned rules, be aware of the following:

  • Operator-created rules are evaluated first and may override any system-created rule that match a given packet.
  • If only PERMIT rules are created by the operator, any packets not matching one of these rules "fall through" and are accepted or discarded according to the system-created rules. In this situation, there is no concern about blocking any essential traffic. Be careful not to be excessive with what you permit.
  • If one or more DISCARD rules are created, they may preempt system-created rules that permit necessary OAM or signaling packet flows. In such cases it may be necessary to create additional compensating PERMIT rules to restore access for those packet flows.
  • If using TCP- or SCTP-based signaling in a peering (non-REGISTERing) deployment, note that TCP or SCTP connections that are initiated outbound from the 
    Unable to show "metadata-from": No such page "_space_variables"
    use unpredictable, ephemeral local port numbers. If operator-created DISCARD rules block incoming packets for these flows, you must create compensating PERMIT rules for that TCP or SCTP traffic (that is with the local (destination) port set to ANY).
  • Media packets (RTP, RTCP) are always processed according to the 
    Unable to show "metadata-from": No such page "_space_variables"
    dynamic media pinhole management and are not subject to ACL filters.

IP ACL Rule Examples

RULE 1: The below rule is an example where 10.11.12.134 is the SBC SIP IP address that phones register with.

% set addressContext "default" ipAccessControlList rule "darkGrayCarrierAccess" precedence "64500" protocol "udp" ipInterfaceGroup "EXTERNAL.IPIG" destinationIpAddress "10.11.12.134" destinationPort "5060" fillRate "556" bucketSize "50" state "enabled"

 
RULE 2: Another example showing the discard action is listed below.

% set addressContext "default" ipAccessControlList rule "DENYALL_ACCESS" precedence "65020" ipInterfaceGroup "EXTERNAL.IPIG" action "discard" 

 

  • No labels