Network rules are applied at the packet level on a Decoder and are made up of rule sets from Layer 2, Layer 3, and Layer 4. Multiple rules can be applied at the packet level to a Decoder. Network rules can apply to multiple network layers (for example, when a network rule filters out specific ports for a specific IP address). Network rules do not apply to Log Decoders, they apply only to Network Decoders.
You can create and manage network rules in the Services Config view > Network Rules tab.
Note: Because network rules are applied on the packet level, you must specify both the source and destination meta keys in the rule condition. This is because the packet flow can occur on both sides at the packet level, while the directions are still not determined. For example, if you want to filter traffic on port 553 and port 55553, the condition should be written as follows:
port.src=553 || port.dst=553 || port.src=55553 || port.dst=55553
You must also specify both the source and destination meta keys in the conditions for ip.src and ip.dst. Specifying only source or destination in the condition will not work as expected.
Supported Meta Keys in Network Rule Conditions
The following table describes the meta keys that NetWitness Platform supports for use in network rule conditions.
|eth.addr||Ethernet source or destination address. Commonly known as the MAC address.|
|eth.dst||Destination Ethernet address. This is the same as the Ethernet address field except that it selects only packets where the destination address matches the selected value(s).|
|eth.src||Same as Ethernet destination except that it focuses on the source address.|
|eth.type||Ethernet frame type.|
|hdlc.type||Frame type of the HDLC frame.|
|alias.ip||IPv4 source or destination address in standard form. IP addresses can be entered in CIDR notation for subnets.|
|ip.dst||Destination IPv4 address in standard form. IP addresses can be entered in CIDR notation for subnets.|
|ip.proto||IPv4 protocol field.|
|ip.src||Source IPv4 address in standard form. IP addresses can be entered in CIDR notation for subnets.|
|alias.ipv6||IPv6 source or destination address in hex format. Generally IPv6|
addresses are written as eight groups of four hex digits, thus expressing
the entire 128 bit address length. Supports notation to represent multiple
blocks of 0000 in an address. Does not support CIDR notation.
|ipv6.dst||Destination IPv6 address in hex format.|
|ip.proto||IPv6 protocol field. This maps to the Next Header field in the IPv6 header|
and uses the same values as the IPv4 protocol field.
|ipv6.src||Source IPv6 address in hex format.|
|port.dst||Destination TCP port.|
|tcp.port||TCP source or destination port.|
|port.src||Source TCP port.|
|port.dst||Destination UDP port.|
|udp.port||UDP source or destination port.|
|port.src||Source UDP port.|
The following are sample network rules.
To truncate all SSL from the source port, create a rule as follows:
- Rule Name: Truncate SSL
- Condition: port.src=443
- Rule Action: Truncate
To filter subnet traffic, create a rule as follows:
- Rule Name: Subnet Filter
- Condition: alias.ip=192.168.2.0/24
- Rule Action: Filter
Meta entities, which provide a way to work with several meta keys at the same time, can be used in application rules, but are not supported in network rules as the metadata available are too limited. For more information on meta entities, see the Core Database Tuning Guide.
To add or edit a network rule:
Go to (Admin) > Services, select a Decoder service, and > View > Config.
The Services Config view for the selected service is displayed.
- Select the Network Rules tab.
The Network Rules tab is displayed.
- In the Network Rules tab, do one of the following:
- If adding a new rule, click .
- If editing a rule, select the rule from the rules list and click .
The Rule Editor dialog is displayed.
- In the Rule Name field, provide a name for the rule. For example, for a rule that truncates all SSL from the source port, type SSL Truncate.
- In the Condition field, build the rule condition that triggers an action when matched. You can type directly in the field or build the condition in this field using meta values from the window actions. As you build the rule definition, NetWitness Platform displays syntax errors and warnings. For example, to truncate all SSL from the source port, tcp.srcport=443.
All string literals and time stamps must be quoted. Do not quote number values and IP addresses. Configure Decoder Rules provides additional details. Supported Meta Keys in Network Rule Conditions describes the meta keys that NetWitness Platform supports for use in network rule conditions.
- If you want rule evaluation to end with this rule, select the Stop Rule Processing checkbox.
- In the Session Data section, choose one of the following actions to apply when a matching packet is found:
- Keep: The packet payload and associated metadata are saved when they match the rule.
- Filter: The packet is not saved when it matches the rule.
- Truncate: The packet payload is not saved when it matches the rule, but packet headers and associated metadata are retained.
- In the Session Options section, select all options that apply of these four.
- Assemble: The assembler assembles the packet chain when it matches the rule.
- Network Meta: The packet generates network metadata when it matches the rule.
- Application Meta: The packet generates application metadata when it matches the rule.
- Alert: The packet generates a custom alert when metadata matches the rule.
- To save the rule and add it to the rules list, click OK.
The rule is added at the end of the list or inserted where you specified in the context menu.
- Check that the rule is in the correct execution sequence with other rules in the list. If necessary, move the rule.
- To apply the updated rule set to the Decoder, click Apply.
NetWitness Platform saves a snapshot of the currently applied rules, then applies the updated set to the Decoder and removes the pending indicator from the rules that were pending.