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.
| Attribute Name | Datatype | Definition |
|---|---|---|
| srcmacaddr | MAC_ADDR | MAC address of sender |
| srcmacmask | MAC_MASK | Mask applied to MAC address of sender |
| dstmacaddr | MAC_ADDR | MAC address of destination |
| dstmacmask | MAC_MASK | Mask applied to MAC address of destination |
| protocolid | UINT16 (0x600-0xffff), STRING | Layer 3 protocol ID. Valid strings include [arp, rarp, ipv4, ipv6] |
| comment | STRING | text string up to 256 characters |
The filter can be written as such:
[...] <mac match='no' srcmacaddr='$MAC'/> [...]
