Access Control list in firewalls : TR-069 support

Access control lists are heart of firewall. ACLs control the traffic among different zones of organizations. Typical firewall implements multiple ACLs with each ACL implementing multiple access control rules. Each rule is defined with L3 & L4 protocol information and in some cases with L7 protocol fields - L3 fields are typically source IP, destination IP and Protocol and L4 fields are typically TCP ports, UDP ports and ICMP type/code values. Some of examples of L7 protocols are HTTP, SMTP, NNTP etc..

Access rule typically contains 'Selectors' and 'Actions'. First packet of every session is matched against the rules. 'Selector' fields are checked as part of matching operation. 'Actions' of matching rule is applied. If there is no match, then the packet is dropped or rejected based on whether stealth mode is enabled or disabled. Note: If stealth mode is enabled, then the packet is dropped. It generates TCP resets to both end points in case stealth mode is disabled. Since the matching operation is terminated upon first match, the access control list is organized as ordered list with first entry being higher priority rule and last entry being lowest priority rule.

'Selectors' fields are typically categorized into 'primary selectors' and 'secondary selectors'. Both kinds of selectors are checked against the packet values and other values in matching operation. If primary selectors are changed during the course of sessions, then the existing sessions are revalidated. In case of secondary selectors, this revalidation does not happen. Zone information (From zone and To Zone) and 5 tuple values in the rules are primary selectors. 'Time window' or 'time schedule' typically considered as a secondary selector. 'Time window' in rules is used to allow/deny connections during some period of week. For example, some connections may not be allowed during day time, but allowed in night time.

'Actions' in the rule decides the connection traversal through the firewall. 'Allow' action lets the connection through the firewall. 'Drop' action drops the packets and 'Reject' action sends the TCP reset (in case of TCP connection) to the client. Allow, Deny and Reject actions are mutually exclusive and these are primary actions. More sub actions are also can be defined.

• 'Log' is one sub-action. This indicates whether the connection is to be logged with logging system. If this option is selected, firewalls typically send 'Connection Start' and 'Connection End' messages to the logging system in case of allowed connections. In case of 'Drop/Reject' actions, log is sent to indicate that the connection was not allowed.
  
• Packet mangling: TOS (Type of Service) or DSCP parameter - This takes new TOS value. Packets are updated with this TOS value if it is configured. This is typically used to increase or reduce the priority of the packet for traffic management purposes. This feature is specifically provided where VOIP/Video devices behind the firewall don't differentiate between data and real time traffic. Another packet mangling parameter that is supported is setting of MSS value in TCP packets having 'SYN' flag. If this parameter is set, then all TCP connections falling on this rule would be changed to this MSS value (if this MSS value is less than the MSS value that is being negotiated in SYN packets). This setting is specifically useful when the WAN uplink bandwidth is is less than 256kbytes/sec. When this value is low, the TCP packets sent by both end points are small in size and hence the packet transmission time is less. Once the packet is submitted to the hardware to transmit, it can't be preempted and that is any new packet has to wait until this packet is sent out. Due to this, VOIP packets also need to wait and this might give rise to lateny and thereby jitter. To reduce the latency and jitter, it is necessary that the data packets which are queued to hardware are small enough. MSS value helps in ensuring that data packets are small.
  
• Rate control: Another sub-action that is supported in rules are controlling the rate in terms of packets, bytes, connections. In addition, even the connection limits also can be controlled by the administrator. If this is configured in the rule, if the traffic falling on this rule exceeds these parameter values, then packets or connections are dropped. If packet or byte rate exceeds across all sessions of this rule is exceeded, then the packets are dropped. If connection rate is exceeded, then the connection establishment does not succeed. Similarly, if number of existing connection due to this rule exceed the maximum connections allowed by this rule, then the connection establishment does not succeed.
• Application protocol command filtering: I am not really fan of keeping the application command filtering as part of each rule. With IPS becoming part of many security devices, this kind of filtering can be achieved through IPS rules/signatures.
• IPS Signature based Intrusion Detection function Control: Many firewall devices are adding Intrusion Prevention feature. As we all know, intrusion detection is CPU consuming function. To reduce the load on the CPU, I feel that firewall function needs to provide flexibility for administrators to disable Intrusion detection on per rule basis.
  
• IPS Traffic Anomaly detection & throttling function control: IPS function provide multiple detection methods. Traffic anomaly is one detection method supported. This function also takes significant CPU cycles and also takes memory to maintain traffic states - some times on per connection basis. Due to this, having control at firewall policy rule helps in tuning the system for performance as well as for the deployments.
• Inactivity timeout: Each session created from this rule inherits this inactivity timeout. If there are no packets within this inactivity timeout period, then the session is deleted. This value is in seconds. If this is not configured i.e if the value is 0, then it session inactivity timeout period determined from other configuration database information.
  

Multiple Access Control Lists:

Firewalls have come long way. Initially, firewall used to implement one ACL. Now, firewalls provide multiple lists to cater to different requirements.

• Normal ACL: This is traditional list. It contains rules for traffic going across zones.
• Dynamic ACL: This list is populated by other services and applications. That is, this list is not generated by the administrator. Rules are typically created in this list when configuration of some other service happens. uPNP and MIDCOM kind of applications create dynamic rules. These dynamic rules go to Dynamic ACL.
• User Group specific ACL: Normal ACL and Dynamic ACL rules are applied to entire traffic by default. Yet times, Enterprises require to provide user specific access control. That is, some privileged users might need to be given access to some important resources, which are prohibited for general users. Similarly, some users might need to be give access only to some particular resources and nothing else. To provide this flexibility, firewalls typically authenticate the user first and activate user specific rules. Providing and creating user specific ACL is big burden for administrators, if the organization has more than 10 users. Many a times, it is possible to categorize users into small number of groups. Administrator only needs to create as many ACLs as number of groups. I am calling these ACLs as 'User Group ACLs'.

Ordering of rule search: Firewall searches dynamic ACL, user group specific ACL and finally generic ACL. If no match, then packet gets dropped.

TR-069 and ordered lists: TR-069 does not have any specific RPC methods for ACS to move the position of rules in devices. Due to this, it is required that data models for any ordered lists have their own parameters to represent the priority. My suggestion is to have 'position' parameter for ordered lists. Lower the position number, higher the priority. ACS in its user interface need not provide 'position' as a configurable parameter. It can rather have intuitive drag and place UI for changing the relative position of the records with respect to others. Internally, ACS can change the 'postition' values of affected records and send them to the devices. Based on movement of records, 'position' value of many records may change though.


With above background, time window and firewall ACL representation in TR-069 can be represented in following way.

• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.timeWindowObject.{i} PC
  
• name : String(32), RW - Name of the object. Once this variable is set, this can't be changed.
  
• Description: String(128) - RW - Value describing the object.
• Day1Begin: String, RW - Staring day of the week - Takes values 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' and 'Sunday'.
  
• Day2Begin: String, RW
• Time1Begin: String, RW: Starting time in hour and minutes. 1:00PM is represented as 13:00 and 2:00PM is represented as 14:00PM and son on.
• Time2Begin: String, RW
• Day2Begin: Same as Day1Begin.
• Day2End: Same as Day1End.
• Time2Begin: Same as Time1Begin.
• Time2End: Same as Time1End.
• Day3Begin:Same as Day1Begin.
• Day3End:Same as Day1Begin.
• Time3Begin: Same as Time1Begin.
• Time3End: Same as Time1End.
• Day4Begin: Same as Day1Begin.
• Day4End:Same as Day1Begin.
• Time4Begin: Same as Time1Begin.
• Time4End: Same as Time1End.
• internetGatewayDevice.security.VirtualInstance.{i}.firewall P
• MaximumNumberOfRules: Read Only. Unsigned Int - This determines the rule ID in each ACL. Rule ID can't exceed this number.
  
• internetGatewayDevice.security.VirtualInstance.{i}.firewall.generalACLRules.{i} PC
• RuleID: Unsigned Int, RW - Identification to the rule. Its value can't exceed 'NumberOfRulesPerACL'. Once reord is created and ruleID is set, this can't be changed. This should be unique within the ACL.
  
• Description: String(128), RW - Description about this rule.
  
• Position: Unsigned Int, RW - This indicates the position of this rule in this list. Note that position values need not be consecutive. Lower the position number, higher the priority of the rule.
  
• Enable : Boolean, RW: 0 or 1 - Indicates whether this rule is enabled or disabled.
• FromZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• ToZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• SourceIPType: String(32), RW - It represents the source IP of the selector. It takes values such as 'immediate', 'ipobject'. Immediate indicaets that IP addresses are given as values and 'ipobject' indicates the IP address information points to one of the IPObjects.
• SourceIPValue: String(64), RW - If the type is immediate, then it can be single IP address in dotted decimal form, subnet by providing network IP address and prefix in terms of number or range of IP addresses with '-' in between low and high values. If the type is 'ipobject', then it has one of ipobject names from internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.IPValueObject.{i} table or internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.IPFQDNObject.{i} table. 'any' is special value indicating all source IP values. Examples: 10.1.5.10 or 10.1.5.0/24 or 10.1.5.1-10.1.5.254
• DestinationIPType: Same as 'Source IP Type'. This represents destination IP selector information.
• DestinationIPValue: Same as 'SourceIPValue'.
• ServiceType : String(64), RW - Represents the Protocol, source port and destination Port part of selectors of the rule. It takes values 'immediate' or 'serviceobject'. In case of 'immediate' type, protocol, source port and destination port values are part of the rule.
  
• ServiceObject: String(32), RW - One of the values of Service Records from the same virtual instance. This parameter is valid only if 'ServiceType' has value 'serviceobject'. 'any' is special value.
  
• Protocol : String(16), RW - It takes values such as 'udp', 'tcp', 'udptcp', 'icmp', 'esp', 'ah', 'ospf', 'ipinip' and integer value in string format representing the protocol value. This parameter is valid only if 'ServiceType' is 'immediate'.
• SourcePort: String(16), RW - It takes a single value or range of port values. Examples: 1214 or 1214-1230. This parameter is valid only if 'ServiceType' is 'immediate'.
• DestinationPort: String(16), RW - It takes a single value or range of port values. Examples: 1214 or 1214-1230. This parameter is valid only if 'ServiceType' is 'immediate'.
• TimeWindow: String(32), RW - It takes 'name' value from timewindow object table. 'none' indicates no timewindow.
• Action : String(16), RW - Action to be taken on the connection matching this rule. It takes values 'allow', 'drop', 'reject'.
• EnableLog: Boolean, RW - If the value 1, it generates logs upon session creation and session termination. Takes value 1 or 0.
  
• EnableTOSMangling: Boolean, RW - If value is 1, then firewall sets the TOS value in the IP header with the value of 'TOS' parameter.
• TOS: unsigned int, RW - Value can't exceed 255. Applicable only if 'EnableTOSMangling' is set to 1.
• EnabelMSSMangling: Boolean, RW - Take values 1 or 0. If set to 1, TCP Option MSS is set with the minimum of value given in 'MSS' parameter and the value in TCP packet.
• MSS: Unsigned int, RW.
• EnableBandwidthRateControl: Boolean, RW - Takes value 1 or 0. If set to 1, 'ByteRate' parameters is valid.
• ByteRate : String(32), RW - It takes form of X/Y - X being number of Kbytes and Y being number of seconds. Example: 10/5 means limit the traffic falling to this policy to 10Kbytes for 5 seconds. This parameter is valid only if 'EnableBandwidthRateControl' is set to 1.
• EnableConnectionRateControl: Boolean, RW - Takes values 1 or 0.
  
• ConnectionRate: String(32), RW - It also takes form of X/Y - X being number of connections and Y being number of seconds. Example: 1000/3600 limits number of connection establishments to 1000 per hour. This parameter is valid only if 'EnableConnectionRateControl' is set to 1.
  
• EnableMaxConnectionsControl: Boolean, RW - takes values 1 or 0.
• MaxConnections: Unsigned Int, RW - Maximum number of connections allowed at any time. Example: 1000 indicates that number of connections falling in this policy rule will not exceed 1000.
• EnableSigBasedIntrusionDetection: Boolean, RW - Takes values 1 or 0. Value 1 enables intrusion analysis.
  
• EnableTrafficAnomalyDetection: Boolean, RW - Takes values 1 or 0. Value 1 enables traffic anomaly detection.
• inactivityTimeout: Unsigned Int, RW - Default is 0. Value represented in seconds.
  
• internetGatewayDevice.security.VirtualInstance.{i}.firewall.dynamicACLRules.{i} P : It is repetition of above table, except that all values are read only.
  
• RuleID: Unsigned Int, Read Only.
  
• Description: String(128), Read Only.
  
• Position: Unsigned Int, Read Only.
  
• Enable : Boolean, Read Only
  
• FromZone: String(32), Read Only.
  
• ToZone: String(32), Read Only.
  
• SourceIPType: String(32), Read Only
  
• SourceIPValue: String(64), Read Only.
  
• DestinationIPType: String(32), Read Only.
  
• DestinationIPValue: String(64), Read Only.
• ServiceType : String(64), Read Only
  
• ServiceObject: String(32), Read Only.
  
• Protocol : String(16), Read Only
  
• SourcePort: String(16), Read Only
  
• DestinationPort: String(16), Read Only
  
• TimeWindow: String(32), Read Only
  
• Action : String(16), Read Only
  
• EnableLog: Boolean, Read Only
  
• EnableTOSMangling: Boolean, Read Only
  
• TOS: unsigned int, Read Only
  
• EnabelMSSMangling: Boolean, Read Only
  
• MSS: Unsigned int, Read Only
  
• EnableBandwidthRateControl: Boolean, Read Only
  
• ByteRate : String(32), Read Only.
  
• EnableConnectionRateControl: Boolean, Read Only.
  
• EnableMaxConnectionsControl: Boolean, Read Only.
  
• MaxConnections: Unsigned Int, Read Only.
  
• EnableSigBasedIntrusionDetection: Boolean, Read Only.
  
• EnableTrafficAnomalyDetection: Boolean, Read Only.
• inactivityTimeout: Unsigned Int, Read Only.
  
• internetGatewayDevice.security.VirtualInstance.{i}.UserGroups.{i} PC
• Name: String(32), RW - Name of the user group. Once this is set, this can't be changed.
• Enable : Boolean, RW - Takes value 1 or 0.
  
• internetGatewayDevice.security.VirtualInstance.{i}.firewall.ACLRules.{i} PC - Following section is repetition of genericACLRules.
  
• RuleID: Unsigned Int, RW - Identification to the rule. Its value can't exceed 'NumberOfRulesPerACL'. Once reord is created and ruleID is set, this can't be changed. This should be unique within the ACL.
  
• Description: String(128), RW - Description about this rule.
  
• Position: Unsigned Int, RW - This indicates the position of this rule in this list. Note that position values need not be consecutive.
  
• Enable : Boolean, RW: 0 or 1 - Indicates whether this rule is enabled or disabled.
• FromZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• ToZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• SourceIPType: String(32), RW - It represents the source IP of the selector. It takes values such as 'immediate', 'ipobject'. Immediate indicaets that IP addresses are given as values and 'ipobject' indicates the IP address information points to one of the IPObjects.
• SourceIPValue: String(64), RW - If the type is immediate, then it can be single IP address in dotted decimal form, subnet by providing network IP address and prefix in terms of number or range of IP addresses with '-' in between low and high values. If the type is 'ipobject', then it has one of ipobject names from internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.IPValueObject.{i} table or internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.IPFQDNObject.{i} table. 'any' is special value indicating all source IP values. Examples: 10.1.5.10 or 10.1.5.0/24 or 10.1.5.1-10.1.5.254
• DestinationIPType: Same as 'Source IP Type'. This represents destination IP selector information.
• DestinationIPValue: Same as 'SourceIPValue'.
• ServiceType : String(64), RW - Represents the Protocol, source port and destination Port part of selectors of the rule. It takes values 'immediate' or 'serviceobject'. In case of 'immediate' type, protocol, source port and destination port values are part of the rule.
  
• ServiceObject: String(32), RW - One of the values of Service Records from the same virtual instance. This parameter is valid only if 'ServiceType' has value 'serviceobject'. 'any' is special value.
  
• Protocol : String(16), RW - It takes values such as 'udp', 'tcp', 'udptcp', 'icmp', 'esp', 'ah', 'ospf', 'ipinip' and integer value in string format representing the protocol value. This parameter is valid only if 'ServiceType' is 'immediate'.
• SourcePort: String(16), RW - It takes a single value or range of port values. Examples: 1214 or 1214-1230. This parameter is valid only if 'ServiceType' is 'immediate'.
• DestinationPort: String(16), RW - It takes a single value or range of port values. Examples: 1214 or 1214-1230. This parameter is valid only if 'ServiceType' is 'immediate'.
• TimeWindow: String(32), RW - It takes 'name' value from timewindow object table. 'none' indicates no timewindow.
• Action : String(16), RW - Action to be taken on the connection matching this rule. It takes values 'allow', 'drop', 'reject'.
• EnableLog: Boolean, RW - If the value 1, it generates logs upon session creation and session termination. Takes value 1 or 0.
  
• EnableTOSMangling: Boolean, RW - If value is 1, then firewall sets the TOS value in the IP header with the value of 'TOS' parameter.
• TOS: unsigned int, RW - Value can't exceed 255. Applicable only if 'EnableTOSMangling' is set to 1.
• EnabelMSSMangling: Boolean, RW - Take values 1 or 0. If set to 1, TCP Option MSS is set with the minimum of value given in 'MSS' parameter and the value in TCP packet.
• MSS: Unsigned int, RW.
• EnableBandwidthRateControl: Boolean, RW - Takes value 1 or 0. If set to 1, 'ByteRate' parameters is valid.
• ByteRate : String(32), RW - It takes form of X/Y - X being number of Kbytes and Y being number of seconds. Example: 10/5 means limit the traffic falling to this policy to 10Kbytes for 5 seconds. This parameter is valid only if 'EnableBandwidthRateControl' is set to 1.
• EnableConnectionRateControl: Boolean, RW - Takes values 1 or 0.
  
• ConnectionRate: String(32), RW - It also takes form of X/Y - X being number of connections and Y being number of seconds. Example: 1000/3600 limits number of connection establishments to 1000 per hour. This parameter is valid only if 'EnableConnectionRateControl' is set to 1.
  
• EnableMaxConnectionsControl: Boolean, RW - takes values 1 or 0.
• MaxConnections: Unsigned Int, RW - Maximum number of connections allowed at any time. Example: 1000 indicates that number of connections falling in this policy rule will not exceed 1000.
• EnableSigBasedIntrusionDetection: Boolean, RW - Takes values 1 or 0. Value 1 enables intrusion analysis.
  
• EnableTrafficAnomalyDetection: Boolean, RW - Takes values 1 or 0. Value 1 enables traffic anomaly detection.
• inactivityTimeout: Unsigned Int, RW - Default is 0. Value represented in seconds.