- Table of Contents
-
- 04-DPI Configuration Guide
- 00-Preface
- 01-DPI overview
- 02-URL filtering configuration
- 03-Data filtering configuration
- 04-File filtering configuration
- 05-Anti-virus configuration
- 06-Proxy policy configuration
- 07-APT defense configuration
- 08-IP reputation configuration
- 09-Domain reputation configuration
- 10-IPS configuration
- 11-DPI engine configuration
- 12-Data analysis center configuration
- 13-DLP configuration
- 14-Network asset scan configuration
- 15-DGA detection configuration
- 16-Intelligent service platform configuration
- 17-IoT device security management configuration
- 18-WAF configuration
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 17-IoT device security management configuration | 274.43 KB |
Configuring IoT device security management
About IoT device security management
Licensing requirements for IoT device security management
Restrictions and guidelines: IoT device security management
Configuring standard format check
Configuring device access control
Configuring basic device access control functions
Configuring the device detection duration
Configuring sensitive signal control
Configuring standard traffic control
Configuring standard traffic control basic functions
Moving standard traffic management policies
Display and maintenance commands for IoT device security management
IoT device security management configuration examples
Example: Configuring standard format check
Example: Configuring device access control
Example: Configuring sensitive signal control
Example: Configuring standard traffic control
Configuring IoT device security management
About IoT device security management
Background
With the rapid development of science and technology, the era of the Internet of Things (IoT) is approaching.
IoT is one of the most important technologies in the digitization era, aiming to connect everything to the Internet. Compared to the traditional Internet, IoT connects a wide variety of devices in large quantities and with a broad scope of applications. Many of these devices, often remote and unattended, are becoming increasingly vulnerable to risks. For example, many endpoint cameras in video security systems are located in remote corners to monitor the surrounding environment. The main security challenges IoT faces are as follows:
· Non-standard device access.
· Illegal device replacements.
· Data leakage and tampering.
· DoS attacks.
Using IoT security management features can effectively ensure the internal security of the IoT, overcome the above challenges, prevent information leakage and network attacks, and safeguard user property security.
Figure 1 Video security management networking
Features
IoT device security management is a technology for intelligent detection and security management of IoT devices, mainly including the following features:
· Standard format check—Checks whether the traffic of IoT devices meet relevant IoT device standards. This feature can effectively prevent access of non-standard devices.
· Device access control—Checks the traffic of IoT devices based on IoT device standards and configured device information. This ensures only traffic from allowed IoT devices can pass and can effectively prevent device tampering.
· Sensitive signal control—Identifies sensitive signals in IoT device traffic based on IoT device standards, and matches and filters relevant sensitive signals in traffic based on the configurations. This feature can detect sensitive behaviors in IoT device traffic, such as queries, access, and control, effectively avoiding data leakage and tampering.
· Standard traffic control—Detects the traffic of IoT devices according to standard traffic control policies, and compares the request count and request rate of a single device with a specific ID against the configured thresholds. The feature can control the traffic of requesting devices and effectively prevent DoS attacks.
As shown in Figure 2, the complete device detection process includes standard format check, device access control, sensitive signal control, and standard traffic control in sequence. If you configure multiple detection features for a device, the device will process packets with these features in the above order. A packet will not be further processed if it has been dropped by one feature.
Figure 2 Device check sequence
Licensing requirements for IoT device security management
The sensitive signal control feature identifies traffic based on sensitive signal information in the APR signature library to implement sensitive signal filtering. Please update the APR signature library to the latest version in time.
To update the APR signature library, you must purchase and install the appropriate license. After the license expires, APR can still use the existing signature library but cannot update the signature library. For more information about updating the APR feature library, see Security Configuration Guide.
Restrictions and guidelines: IoT device security management
Currently, IoT device security management-related features support intelligent detection and management of only IoT devices that adopt the GB/T 28181, GB 35114, or GA/T 1400 standard.
Tasks at a glance
To configure IoT device security management, perform the following tasks:
1. Configuring standard format check
2. Configuring device access control
¡ Configuring basic device access control functions
¡ Configuring the device detection duration
¡ (Optional.) Configuring reauthentication
3. Configuring sensitive signal control
4. Configuring standard traffic control
¡ Configuring standard traffic control basic functions
¡ Configuring the alarm period
¡ (Optional.) Moving standard traffic management policies
Configuring standard format check
About this task
The standard format check feature checks whether the IoT-related traffic passing through the device meets the relevant IoT standard, so as to prevent access from illegal IoT devices.
Figure 3 Standard format check process
The standard format check process is as follows:
1. The device checks whether the source address of the IoT-related traffic passing through it is on the allowlist.
¡ If yes, the device permits the traffic.
¡ If not, the device performs the next step.
2. The device checks whether the traffic matches the filtering criteria for format check based on the source address.
You can configure IPv4, IPv6, and MAC source address object groups as the filtering criteria for matching the source addresses of packets. You can configure only one address object group of the same type. The relationship between different types of address object groups is OR. As long as one object group is matched, the match is successful.
¡ If the traffic does not match the filtering criteria, the device permits the traffic.
¡ If the traffic matches the filtering criteria, the device performs the next step.
3. The device checks whether the traffic meets a specific IoT standard based on the configured administrative area attributes, device ID, IoT device type, interface method, and other detection attributes.
¡ If the traffic meets all detection attributes of the standard, the device permits the traffic.
¡ If the traffic does not meet the standard, the device drops or permits the traffic based on the configured action.
Restrictions and guidelines
The device detects only IoT-related traffic that meets the filtering criteria, and directly permits other IoT-related traffic. As a best practice, configure the filtering criteria to match all IoT devices.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter format-check view.
format-check
4. Enter format-check standard view.
standard standard-type
5. Configure source address object groups as the format check filtering criteria.
source-address object-group { ipv4 | ipv6 | mac } object-group-name
By default, no source address object groups are configured as the format check filtering criteria.
6. Configure detection attributes for the standard.
inspect-attribute { administrative-area | device-id | device-type | interface-method } *
By default, no detection attributes are configured for the standard.
7. Set the actions for format check failures.
action { drop | permit } [ logging ]
By default, the action for format check failures is permit.
8. Enable format check for the specified standard.
enable
By default, format check for the specified standard is disabled.
9. Return to format-check view.
quit
10. (Optional) Configure the format check allowlist.
format-allowlist object-group { ipv4 | ipv6 | mac } object-group-name
By default, the format check allowlist is not configured.
If you highly trust some IoT access devices or format check misidentification occurs, you can add the corresponding address object groups to the allowlist to improve device processing efficiency or reduce misidentification.
Configuring device access control
Configuring basic device access control functions
About this task
The device access control feature determines whether all traffic passing through it can be forwarded based on the configured device authentication information. This prevents untrusted devices from accessing the IoT or replacing existing devices.
Figure 4 Device access control process
The device access control process is as follows:
1. The device checks whether the source address of the traffic passing through it is on the allowlist.
¡ If yes, the device permits the traffic.
¡ If not, the device performs the next step.
2. The device checks whether the traffic matches the filtering criteria for device access control based on the source address.
You can configure IPv4, IPv6, and MAC source address object groups as the filtering criteria for matching the source addresses of packets. You can configure only one address object group of the same type. The relationship between different types of address object groups is OR. As long as one object group is matched, the match is successful.
¡ If the traffic does not match the filtering criteria, the device permits the traffic.
¡ If the traffic matches the filtering criteria, the device performs the next step.
3. The device determines whether the traffic can be forwarded on the device based on the configured authentication information such as IP address, MAC address, device ID, and standards.
¡ If the traffic meets all authentication information, the device permits the traffic.
¡ If the traffic does not meet the authentication information, the device drops or permits the traffic based on the configured action.
Restrictions and guidelines
The device access control feature drops all traffic that does not meet the filtering criteria, including the traffic that does not meet the GB/T 28181, GB 35114, or GA/T 1400 standard. As a best practice, disable this feature if it is not required.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter access-control view.
access-control
4. Configure source address object groups as the filtering criteria for device access control.
source-address object-group { ipv4 | ipv6 | mac } object-group-name
By default, no source address object groups are configured as the filtering criteria for device access control.
5. Configure authentication information for IoT devices.
device-info { { ipv4 ipv4-address | ipv6 ipv6-address } | mac mac-address } * [ device-id id { standard standard-type } &<1-n> ]
By default, no authentication information for IoT devices is configured.
6. (Optional) Import IoT device information in bulk.
import-device-info file-path
7. Set the actions performed by device access control for authentication failures.
action { drop | permit } [ logging ]
By default, the action performed by device access control for authentication failures is permit.
8. Enable device access control.
enable
By default, device access control is disabled.
9. (Optional) Configure the device access control allowlist.
access-allowlist object-group { ipv4 | ipv6 | mac } object-group-name
By default, the device access control allowlist is not configured.
If you highly trust some IoT access devices or device access control misidentification occurs, you can add the corresponding address object groups to the allowlist to improve device processing efficiency or reduce misidentification.
Configuring the device detection duration
About this task
If the IoT device information collected from the packets is incomplete, the device cannot authenticate access devices. Thus, you need to set an appropriate device detection duration.
If the device collects the required complete IoT device authentication information within the duration, the device will perform the authentication. If the device cannot collect the required complete information when the detection duration expires, it determines an authentication failure occurs. The device will process the traffic received before obtaining the complete information according to the configured authentication failure actions.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter access-control view.
access-control
4. Configure the device detection duration.
detect-duration time
By default, the device detection duration is 60 seconds.
Configuring reauthentication
About this task
When you modify the information such as the device IDs or standard types of IoT devices through an IoT management platform, the authentication results for the devices authenticated before the modification might become inaccurate. You can use this feature to reauthenticate the specified traffic.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter access-control view.
access-control
4. Reauthenticate the specified IoT devices.
re-authenticate { all | { ipv4 ipv4-address | ipv6 ipv6-address } [ mac mac-address ] | mac mac-address }
Configuring sensitive signal control
About this task
The sensitive signal control feature checks whether the IoT-related traffic passing through the device contains sensitive behavior signals such as queries, access, and control, effectively preventing data leakage and tampering.
Figure 5 Sensitive signal control process
The sensitive signal control process is as follows:
1. The device checks whether the source address of the IoT-related traffic passing through it is on the allowlist.
¡ If yes, the device permits the traffic.
¡ If not, the device performs the next step.
2. The device checks whether the traffic matches the filtering criteria for sensitive signal control based on the source address.
You can configure IPv4, IPv6, and MAC source address object groups as the filtering criteria for matching the source addresses of packets. You can configure only one address object group of the same type. The relationship between different types of address object groups is OR. As long as one object group is matched, the match is successful.
¡ If the traffic does not match the filtering criteria, the device permits the traffic.
¡ If the traffic matches the filtering criteria, the device performs the next step.
3. The device checks whether the traffic contains the configured sensitive signals.
¡ If the traffic does not contain the configured sensitive signals, the device permits the traffic.
¡ If the traffic contains the configured sensitive signals, the device drops or permits the traffic based on the configured action.
Restrictions and guidelines
The device detects only IoT-related traffic that meets the filtering criteria, and directly permits other IoT-related traffic. As a best practice, configure the filtering criteria to match all IoT devices.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter signal-control view.
signal control
4. Enter signal-control standard view.
standard standard-type
5. Configure source address object groups as the filtering criteria for sensitive signal control.
source-address object-group { ipv4 | ipv6 | mac } object-group-name
By default, no source address object groups are configured as the filtering criteria for sensitive signal control.
6. Specify sensitive signals for a standard.
signal-select category category-name [ signal signal-name ]
By default, no sensitive signals are specified for a standard.
7. Set the actions for packets containing sensitive signals.
action { drop | permit } [ logging ]
By default, the action for packets containing sensitive signals is permit.
8. Enable sensitive signal control for the specified standard.
enable
By default, sensitive signal control for the specified standard is disabled.
9. Return to signal-control view.
quit
10. (Optional) Configure the sensitive signal allowlist.
signal-allowlist object-group { ipv4 | ipv6 | mac } object-group-name
By default, the sensitive signal allowlist is not configured.
If you highly trust some IoT access devices or sensitive signal control misidentification occurs, you can add the corresponding address object groups to the allowlist to improve device processing efficiency or reduce misidentification.
Configuring standard traffic control
Configuring standard traffic control basic functions
About this task
The standard traffic control feature allows you to configure various control policies to monitor IoT device traffic passing through the device. When an IoT device sends a large number of requests or its request rate is too high in a short period, the device drops the traffic from the IoT device as configured to prevent DoS attacks.
Figure 6 Standard traffic control process
The standard traffic control process is as follows:
1. The device checks whether the IoT-related traffic matches the filtering criteria for standard traffic control based on the device IDs, IP addresses, MAC addresses, and IoT-related standards of requesting devices configured in the policy.
¡ If a packet matches all types of filtering criteria in a standard traffic control policy, the packet matches this policy. The relationship between multiple matching items of each type of filtering criteria is OR. A packet matches a type of filtering criteria if it matches any one matching item of the type.
¡ If the packet does not match any type of filtering criteria in this policy, it fails to match this policy and will proceed to match the next policy. This process continues until the packet matches a policy. If no matching policy is found when the last policy is processed, the device will not perform standard traffic control on the packet.
2. If the packet matches the filtering criteria for standard traffic control, the device determines whether to take the action in the matching policy based on the configured thresholds for the request count and request rate of a single device.
¡ If the traffic has not reached the thresholds, the device permits the traffic.
¡ If the traffic has reached the thresholds, the device drops or permits the traffic based on the action configured in the standard traffic control policy.
Restrictions and guidelines
The device detects only IoT-related traffic that meets the filtering criteria, and directly permits other IoT-related traffic. As a best practice, configure the filtering criteria to match all IoT devices.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter standard traffic-control view.
flow-control
4. Enter standard traffic control policy view.
policy name policy-name
5. Configure source address object groups as the filtering criteria for the standard traffic control policy.
match-address-object { ipv4 | ipv6 } object-group-name
By default, no source address object groups are configured as the filtering criteria for the standard traffic control policy.
6. Specify a standard as a filtering criterion for the standard traffic control policy.
match-standard standard-type
By default, no standard is configured as a filtering criterion for the standard traffic control policy.
7. Configure IoT device information as the filtering criteria for the standard traffic control policy.
match-device-info device-id device-id [ ipv4 ipv4-address | ipv6 ipv6-address ] [ mac mac-address ]
By default, no IoT device information is configured as the filtering criteria for the standard traffic control policy.
8. Configure the judgment conditions for the standard traffic control policy.
judge-condition { requests-per-id number | request-rate-per-id rate } *
By default, no judgment conditions are configured for the standard traffic control policy.
9. Set the relationship between the judgment conditions for the standard traffic control policy.
judge-logic { and | or }
By default, the relationship between the judgment conditions is OR.
10. Set the actions for the standard traffic control policy.
flow-action { drop | permit } [ logging ]
By default, the action for the standard traffic control policy is permit.
11. (Optional.) Disable the specified standard traffic control policy.
disable
By default, the standard traffic control policy is enabled.
Configuring the alarm period
About this task
To prevent the device from continuously sending a large number of standard traffic control logs and affecting the device performance, set a period for sending standard traffic control logs. When an IoT access device hits a policy, it checks whether the time elapsed since the last time the access device hit this policy has exceeded the alarm period. If yes, the device sends the standard traffic control log message. If not, the device will not send the log message.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter standard traffic-control view.
flow-control
4. Configure the alarm period.
warning-period time
By default, the alarm period is 5 minutes.
Moving standard traffic management policies
About this task
The device matches the traffic based on the standard traffic control policies displayed from top to bottom on the device. Once a policy is matched, the matching process ends and the device takes the actions configured in the policy on the traffic. If no matching policy is found, the device permits the traffic.
To achieve better and more rigorous standard traffic control, prioritize precise standard traffic control policies over broader ones. If the order of the standard traffic control policies configured on the device does not comply with this principle, use this feature to adjust the order of the policies.
Procedure
1. Enter system view.
system-view
2. Enter IoT device security management view.
iot security-manage
3. Enter standard traffic-control view.
flow-control
4. (Optional) Move a standard traffic control policy.
policy move policy-name1 { after | before } [ policy-name2 ]
Display and maintenance commands for IoT device security management
Execute the display commands in any view. Execute the reset command in user view.
|
Task |
Command |
|
Display details about all IoT device sensitive signals supported in the signature library. |
display iot security-manage signal-control signal-detail |
|
Display statistics of a standard traffic control policy. |
display iot security-manage flow-control statistics policy name policy-name [ slot slot-number ] |
|
Clear the statistics of all requesting device IDs in a standard traffic control policy. |
reset iot security-manage flow-control statistics policy name policy-name |
IoT device security management configuration examples
Example: Configuring standard format check
Network configuration
As shown in Figure 7, the device is connected to the IoT management platform through security zone Trust and to the IoT endpoint devices through security zone Untrust. Configure the device to detect IoT access device traffic according to the GB/T 28181 standard, so as to prevent IoT devices that do not use the standard from accessing the network.
Procedure
1. Assign IP addresses to interfaces:
# Assign an IP address to interface GigabitEthernet 1/0/1.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip address 192.168.1.1 255.255.255.0
[Device-GigabitEthernet1/0/1] quit
# Assign IP addresses to other interfaces in the same way. (Details not shown.)
2. Add interfaces to security zones.
[Device] security-zone name trust
[Device-security-zone-Trust] import interface gigabitethernet 1/0/1
[Device-security-zone-Trust] quit
[Device] security-zone name untrust
[Device-security-zone-Untrust] import interface gigabitethernet 1/0/2
[Device-security-zone-Untrust] quit
3. Create an IP address object group named abc and add IPv4 subnet address 192.168.2.0 with a mask of 255.255.255.0 to the object group.
[Device] object-group ip address abc
[Device-obj-grp-ip-web] network subnet 192.168.2.0 255.255.255.0
[Device-obj-grp-ip-web] quit
4. Enable standard format check to detect IoT access devices. Configure the device to permit only traffic from IoT devices that meet the GB/T 28181 standard. Set the actions for traffic that does not meet the standard to drop and logging.
[Device] iot security-manage
[Device-iot-sec] format-check
[Device-iot-sec-format-check] standard GBT28181
[Device-iot-sec-format-check-GBT28181] source-address object-group ipv4 abc
[Device-iot-sec-format-check-GBT28181] inspect-attribute administrative-area device-id device-type interface-method
[Device-iot-sec-format-check-GBT28181] action drop logging
[Device-iot-sec-format-check-GBT28181] enable
[Device-iot-sec-format-check-GBT28181] quit
[Device-iot-sec-format-check] quit
[Device-iot-sec] quit
5. Create a security policy rule named trust-untrust to allow mutual access between the IoT devices in both security zones.
[Device] security-policy ip
[Device-security-policy-ip] rule name trust-untrust
[Device-security-policy-ip-1-trust-untrust] source-zone trust
[Device-security-policy-ip-1-trust-untrust] source-zone untrust
[Device-security-policy-ip-1-trust-untrust] destination-zone trust
[Device-security-policy-ip-1-trust-untrust] destination-zone untrust
[Device-security-policy-ip-1-trust-untrust] action pass
[Device-security-policy-ip-1-trust-untrust] quit
[Device-security-policy-ip] quit
Verifying the configuration
After the configuration takes effect, only IoT devices using the GB/T 28181 standard can communicate with the management platform. IoT devices not using the GB/T 28181 standard cannot communicate with the management platform.
Example: Configuring device access control
Network configuration
As shown in Figure 8, the device is connected to the IoT management platform through security zone Trust and to the IoT endpoint devices through security zone Untrust. Configure the device to detect IoT device traffic based on different IoT device standards and configured device information, so as to permit only traffic from allowed devices and avoid device tampering.
Procedure
1. Assign IP addresses to interfaces:
# Assign an IP address to interface GigabitEthernet 1/0/1.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip address 192.168.1.1 255.255.255.0
[Device-GigabitEthernet1/0/1] quit
# Assign IP addresses to other interfaces in the same way. (Details not shown.)
2. Add interfaces to security zones.
[Device] security-zone name trust
[Device-security-zone-Trust] import interface gigabitethernet 1/0/1
[Device-security-zone-Trust] quit
[Device] security-zone name untrust
[Device-security-zone-Untrust] import interface gigabitethernet 1/0/2
[Device-security-zone-Untrust] quit
3. Create an IP address object group named abc and add IPv4 subnet address 192.168.2.0 with a mask of 255.255.255.0 to the object group.
[Device] object-group ip address abc
[Device-obj-grp-ip-web] network subnet 192.168.2.0 255.255.255.0
[Device-obj-grp-ip-web] quit
4. Configure device access control to detect IoT access devices. Configure the device to permit only traffic from IoT devices that matches the configured authentication information. Set the actions for traffic that does not match the authentication information to drop and logging. (This example configures only one piece of device information.)
[Device] iot security-manage
[Device-iot-sec] access-control
[Device-iot-sec-access-control] source-address object-group ipv4 abc
[Device-iot-sec-access-control] device-info ipv4 192.168.2.2 device-id 12345678901234567890 standard GBT28181 GB35114 GAT1400
[Device-iot-sec-access-control] action drop logging
[Device-iot-sec-access-control] enable
[Device-iot-sec-access-control] quit
[Device-iot-sec] quit
5. Create a security policy rule named trust-untrust to allow mutual access between IoT devices in both security zones.
[Device] security-policy ip
[Device-security-policy-ip] rule name trust-untrust
[Device-security-policy-ip-1-trust-untrust] source-zone trust
[Device-security-policy-ip-1-trust-untrust] source-zone untrust
[Device-security-policy-ip-1-trust-untrust] destination-zone trust
[Device-security-policy-ip-1-trust-untrust] destination-zone untrust
[Device-security-policy-ip-1-trust-untrust] action pass
[Device-security-policy-ip-1-trust-untrust] quit
[Device-security-policy-ip] quit
Verifying the configuration
After the configuration takes effect, only IoT devices whose device information is consistent with the configured device authentication information can communicate with the management platform. IoT devices that fail authentication are not able to communicate with the management platform.
Example: Configuring sensitive signal control
Network configuration
As shown in Figure 9, the device is connected to the IoT management platform through security zone Trust and to the IoT endpoint devices through security zone Untrust. Configure the device to identify whether the packets from IoT access devices using the GB/T 28181 standard contain any sensitive behaviors of the query category. If a packet using the standard contains such sensitive behaviors, the device will drop the packet to avoid data leakage.
Procedure
1. Assign IP addresses to interfaces:
# Assign an IP address to interface GigabitEthernet 1/0/1.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip address 192.168.1.1 255.255.255.0
[Device-GigabitEthernet1/0/1] quit
# Assign IP addresses to other interfaces in the same way. (Details not shown.)
2. Add interfaces to security zones.
[Device] security-zone name trust
[Device-security-zone-Trust] import interface gigabitethernet 1/0/1
[Device-security-zone-Trust] quit
[Device] security-zone name untrust
[Device-security-zone-Untrust] import interface gigabitethernet 1/0/2
[Device-security-zone-Untrust] quit
3. Create an IP address object group named abc and add IPv4 subnet address 192.168.2.0 with a mask of 255.255.255.0 to the object group.
[Device] object-group ip address abc
[Device-obj-grp-ip-web] network subnet 192.168.2.0 255.255.255.0
[Device-obj-grp-ip-web] quit
4. Configure sensitive signal control to detect the traffic generated by IoT access devices using the GB/T 28181 standard. Configure the device to permit only traffic from IoT devices that do not contain sensitive behaviors of the query category. Set the actions for traffic that contain such behaviors to drop and logging.
[Device] iot security-manage
[Device-iot-sec] signal-control
[Device-iot-sec-signal-control] standard GBT28181
[Device-iot-sec-signal-control-GBT28181] source-address object-group ipv4 abc
[Device-iot-sec-signal-control-GBT28181] signal-select category queryclass
[Device-iot-sec-signal-control-GBT28181] action drop logging
[Device-iot-sec-signal-control-GBT28181] enable
[Device-iot-sec-signal-control-GBT28181] quit
[Device-iot-sec-signal-control] quit
[Device-iot-sec] quit
5. Create a security policy rule named trust-untrust to allow mutual access between IoT devices in both security zones.
[Device] security-policy ip
[Device-security-policy-ip] rule name trust-untrust
[Device-security-policy-ip-1-trust-untrust] source-zone trust
[Device-security-policy-ip-1-trust-untrust] source-zone untrust
[Device-security-policy-ip-1-trust-untrust] destination-zone trust
[Device-security-policy-ip-1-trust-untrust] destination-zone untrust
[Device-security-policy-ip-1-trust-untrust] action pass
[Device-security-policy-ip-1-trust-untrust] quit
[Device-security-policy-ip] quit
Verifying the configuration
After the configuration takes effect, if any traffic using the GB/T 28181 standard contains sensitive behaviors of the query category, the device will drop the traffic.
Example: Configuring standard traffic control
Network configuration
As shown in Figure 10, the device is connected to the IoT management platform through security zone Trust and to the IoT endpoint devices through security zone Untrust. Configure the device to detect traffic based on different standard traffic control policies. If an IoT device using the GB/T 28181 standard matches the device information in the policy, the device will compare the IoT device's request count and other information with the configured thresholds. This can control the traffic of IoT devices and avoid DoS attacks.
Procedure
1. Assign IP addresses to interfaces:
# Assign an IP address to interface GigabitEthernet 1/0/1.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip address 192.168.1.1 255.255.255.0
[Device-GigabitEthernet1/0/1] quit
# Assign IP addresses to other interfaces in the same way. (Details not shown.)
2. Add interfaces to security zones.
[Device] security-zone name trust
[Device-security-zone-Trust] import interface gigabitethernet 1/0/1
[Device-security-zone-Trust] quit
[Device] security-zone name untrust
[Device-security-zone-Untrust] import interface gigabitethernet 1/0/2
[Device-security-zone-Untrust] quit
3. Create an IP address object group named abc and add IPv4 subnet address 192.168.2.0 with a mask of 255.255.255.0 to the object group.
[Device] object-group ip address abc
[Device-obj-grp-ip-web] network subnet 192.168.2.0 255.255.255.0
[Device-obj-grp-ip-web] quit
4. Configure standard traffic control policy p1 to detect IoT access devices. Set the requests-per-id threshold to 12 and configure IoT device information for the policy. This example configures only one piece of device information. If an IoT access device matches the policy, the device will count the requests from the IoT access device. When the request count exceeds 12, the device will drop the traffic from this IoT access device.
[Device] iot security-manage
[Device-iot-sec] flow-control
[Device-iot-sec-flow-control] policy name p1
[Device-iot-sec-flow-control-policy-p1] source-address object-group ipv4 abc
[Device-iot-sec-flow-control-policy-p1] match-standard GBT28181
[Device-iot-sec-flow-control-policy-p1] match-device-info device-id 12345678901234567890 ipv4 192.168.2.2
[Device-iot-sec-flow-control-policy-p1] judge-condition requests-per-id 12
[Device-iot-sec-flow-control-policy-p1] flow-action drop
[Device-iot-sec-flow-control-policy-p1] quit
[Device-iot-sec-flow-control] quit
[Device-iot-sec] quit
5. Create a security policy rule named trust-untrust to allow mutual access between IoT devices in both security zones.
[Device] security-policy ip
[Device-security-policy-ip] rule name trust-untrust
[Device-security-policy-ip-1-trust-untrust] source-zone trust
[Device-security-policy-ip-1-trust-untrust] source-zone untrust
[Device-security-policy-ip-1-trust-untrust] destination-zone trust
[Device-security-policy-ip-1-trust-untrust] destination-zone untrust
[Device-security-policy-ip-1-trust-untrust] action pass
[Device-security-policy-ip-1-trust-untrust] quit
[Device-security-policy-ip] quit
Verifying the configuration
After the configuration takes effect, if an IoT device sends more than 12 requests, it will be unable to communicate with the management platform.










