Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

18.12.10. Supported Protocols

The following sections list and give some details about the protocols that are supported by the network filtering subsystem. This type of traffic rule is provided in the rule node as a nested node. Depending on the traffic type a rule is filtering, the attributes are different. The above example showed the single attribute srcipaddr that is valid inside the ip traffic filtering node. The following sections show what attributes are valid and what type of data they are expecting. The following datatypes are available:
  • UINT8 : 8 bit integer; range 0-255
  • UINT16: 16 bit integer; range 0-65535
  • MAC_ADDR: MAC address in dotted decimal format, such as 00:11:22:33:44:55
  • MAC_MASK: MAC address mask in MAC address format, such as FF:FF:FF:FC:00:00
  • IP_ADDR: IP address in dotted decimal format, such as 10.1.2.3
  • IP_MASK: IP address mask in either dotted decimal format (255.255.248.0) or CIDR mask (0-32)
  • IPV6_ADDR: IPv6 address in numbers format, such as FFFF::1
  • IPV6_MASK: IPv6 mask in numbers format (FFFF:FFFF:FC00::) or CIDR mask (0-128)
  • STRING: A string
  • BOOLEAN: 'true', 'yes', '1' or 'false', 'no', '0'
  • IPSETFLAGS: The source and destination flags of the ipset described by up to 6 'src' or 'dst' elements selecting features from either the source or destination part of the packet header; example: src,src,dst. The number of 'selectors' to provide here depends on the type of ipset that is referenced
Every attribute except for those of type IP_MASK or IPV6_MASK can be negated using the match attribute with value no. Multiple negated attributes may be grouped together. The following XML fragment shows such an example using abstract attributes.
[...]
  <rule action='drop' direction='in'>
    <protocol match='no' attribute1='value1' attribute2='value2'/>
    <protocol attribute3='value3'/>
  </rule>
[...]
Rules behave evaluate the rule as well as look at it logically within the boundaries of the given protocol attributes. Thus, if a single attribute's value does not match the one given in the rule, the whole rule will be skipped during the evaluation process. Therefore, in the above example incoming traffic will only be dropped if: the protocol property attribute1 does not match both value1 and the protocol property attribute2 does not match value2 and the protocol property attribute3 matches value3.

18.12.10.1. MAC (Ethernet)

Protocol ID: mac
Rules of this type should go into the root chain.

Table 18.3. MAC protocol types

Attribute NameDatatypeDefinition
srcmacaddrMAC_ADDRMAC address of sender
srcmacmaskMAC_MASKMask applied to MAC address of sender
dstmacaddrMAC_ADDRMAC address of destination
dstmacmaskMAC_MASKMask applied to MAC address of destination
protocolidUINT16 (0x600-0xffff), STRINGLayer 3 protocol ID. Valid strings include [arp, rarp, ipv4, ipv6]
commentSTRING text string up to 256 characters
The filter can be written as such:
[...]
<mac match='no' srcmacaddr='$MAC'/>
[...]