Bu sayfa henüz yerel dilinizde mevcut değildir. Daha fazla dil seçeneği eklemek için yoğun bir şekilde çalışıyoruz. Desteğiniz için teşekkür ederiz.
- What's New
- Product Bulletin
- Service Overview
- Billing
-
Getting Started
-
Quick Device Access - Property Reporting and Command Receiving
- Subscribing to IoTDA
- Connecting a Smart Smoke Detector to the Platform (Quick Usage)
- Registering a Simulated Smart Street Light Device
- Using MQTT.fx to Simulate Communication Between the Smart Street Light and the Platform
- Using a Virtual Smart Street Light to Communicate with the Platform (Java SDK)
- Using a Virtual Smart Street Light to Communicate with the Platform (C SDK)
- Quick Device Access - Message Sending and Receiving
- Quick Application Access
-
Quick Device Access - Property Reporting and Command Receiving
-
User Guide
- Overview
- IoTDA Instances
- Resource Spaces
- Device Access
- Message Communications
- Device Management
-
Rules
- Overview
- Data Forwarding Process
- SQL Statements
- Connectivity Tests
- Data Forwarding to Huawei Cloud Services
- Data Forwarding to Third-Party Applications
- Data Forwarding Channel Details
- Data Forwarding Stack Policies
- Data Forwarding Flow Control Policies
- Abnormal Data Target
- Device Linkage
- Monitoring and O&M
- Granting Permissions Using IAM
-
Best Practices
- Introduction
-
Device Access
- Developing an MQTT-based Simulated Smart Street Light Online
- Developing a Smart Street Light Using NB-IoT BearPi
- Developing a Smart Smoke Detector Using NB-IoT BearPi
- Connecting and Debugging an NB-IoT Smart Street Light Using a Simulator
- Developing a Protocol Conversion Gateway for Access of Generic-Protocol Devices
- Connecting a Device That Uses the X.509 Certificate Based on MQTT.fx
- Connecting to IoTDA Based on the BearPi-HM_Nano Development Board and OpenHarmony 3.0
- Testing MQTT Performance Using JMeter
- Device Management
- Data Forwarding
- Device Linkage
-
Developer Guide
- Before You Start
- Obtaining Resources
- Product Development
- Development on the Device Side
- Development on the Application Side
-
API Reference
-
API Reference on the Application Side
- Before You Start
- Calling APIs
- API Overview
-
API
- Product Management
- Device Management
- Device Message
- Device Command APIs
- Device Property
- AMQP Queue Management
- Access Credential Management
- Data Forwarding Rule Management
-
Transition Data
- Push a Device Status Change Notification
- Push a Device Property Reporting Notification
- Push a Device Message Status Change Notification
- Push a Batch Task Status Change Notification
- Push a Device Message Reporting Notification
- Push a Device Addition Notification
- Push a Device Update Notification
- Push a Device Deletion Notification
- Push a Product Addition Notification
- Push a Product Update Notification
- Push a Product Deletion Notification
- Push an Asynchronous Device Command Status Change Notification
- Rule Management
- Device Shadow
- Group Management
- Tag Management
- Instance Management
- Resource Space Management
- Batch Task
- Device CA Certificate Management
- OTA Upgrade Package Management
- Message Broadcasting
- Device Tunnel Management
- Stack policy management
- Flow control policy management
- Device Proxy
- Device Policy Management
- Bridge Management
- Pre-provisioning Template Management
- Custom Authentication
- Codec Function Management
- Permissions and Supported Actions
- Examples
- Appendix
-
MQTT or MQTTS API Reference on the Device Side
- Before You Start
- Communication Modes
- Topics
- Device Connection Authentication
- Device Commands
- Device Messages
- Device Properties
-
Gateway and Child Device Management
- Platform Notifying a Gateway of New Child Device Connection
- Platform Notifying a Gateway of Child Device Deletion
- Gateway Synchronizing Child Device Information
- Gateway Updating Child Device Status
- Responding to a Request for Updating Child Device Statuses
- Gateway Requesting for Adding Child Devices
- Platform Responding to a Request for Adding Child Devices
- Gateway Requesting for Deleting Child Devices
- Platform Responding to a Request for Deleting Child Devices
- Software and Firmware Upgrade
- File Upload and Download
- Device Time Synchronization
- Device Reporting Information
- Device Log Collection
- Remote Configuration
- Device Tunnel Management
- HTTPS API Reference on the Device Side
- LwM2M API Reference on the Device Side
- Security Tunnel WebSocket API Reference
- Module AT Command Reference
- Change History
-
API Reference on the Application Side
- SDK Reference
-
FAQs
- Top FAQs
-
Solution Consulting
- In What Scenarios Can the IoT Platform Be Applied?
- What Are the Changes Brought by the Integration of IoT Device Management and IoTDA?
- Can I Enable IoTDA for IAM Users or Sub-Projects?
- Which Regions of Huawei Cloud Are Supported by the IoT Platform?
- Does Huawei Provide Modules, Hardware Devices, and Application Software?
- What Should I Do If I Want to Call an API But Have No Permissions to Do So as an IAM User? (Is It Edition-specific?)
- Why Was I Prompted to Grant Security Administrator Permissions When I Create a Rule or Set Resource File Storage?
- Which Resource Space Will Be Set As Default on the IoT Platform?
- How Does IoTDA Obtain Device Data?
- Is There Any Limitation on the Number of Resource Spaces and Devices I Can Add on the IoT Platform?
- Does the IoTDA Support Device Registration in Batches?
- Are There Any Limitations on the Use of the IoT Platform?
- What DTLS Encryption Algorithms Are Supported by the IoT Platform?
- Does the IoT Platform Support Conversion Between Big-Endian and Little-Endian for Binary Data?
- What Is NB-IoT?
- What Are the Components of the IoT Platform and What Hardware Architectures Does It Support?
- How Do I Obtain the Platform Access Address?
- Device Integration
- IoT Device SDKs
- LwM2M/CoAP Device Access
- MQTT-based Device Access
- Products Models
- Message Communications
- Subscription and Push
- Codecs
- OTA Upgrades
- Application Integration
- General Reference
Copied.
Anomaly Detection
IoTDA provides device anomaly detection functions, including security checks and disconnection analysis.
Security Checks
IoTDA continuously detects device security threats. This section describes security check items and how to view and handle detected security risks.
Common detection items
Item |
Description |
---|---|
Connection mode |
No encryption protocol is used to establish secure connections between devices and IoTDA. This may cause man-in-the-middle and replay attacks and affect services. |
TLS version |
Insecure TLS protocol versions (TLS v1.0 and v1.1) have security vulnerabilities, which may cause security risks such as device data leakage. |
Cryptographic algorithm suite |
Currently, IoTDA checks the following insecure cryptographic algorithm suites: TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, TLS_PSK_WITH_AES_128_CBC_SHA, TLS_PSK_WITH_AES_256_CBC_SHA Insecure cryptographic algorithm suites have security vulnerabilities, which may cause security risks such as device data leakage. |
Device connection |
If a device attempts to establish connections with IoTDA multiple times within 1 second, the device may be cracked with brute force. As a result, identity information may be leaked, normal devices may be forced to go offline, and service data may be stolen. |
Device authentication |
Incorrect device identity authentication information causes device connection failures. This may affect services. |
The preceding common check items are enabled by default. You can manually enable other non-common check items as required.
Item |
Description |
---|---|
Memory leak check |
Checks device memory leaks. |
Abnormal port |
Checks whether abnormal ports are enabled on the device. |
CPU usage |
Checks whether the CPU usage of the device is too high. |
Disk space |
Checks whether the disk space of the device is insufficient. |
Battery level |
Checks whether the battery level of the device is too low. |
Malicious IP address |
Checks whether the device communicates with malicious IP addresses. |
Local login |
Checks whether attackers log in to the device through non-SSH networks. |
Brute-force cracking login |
Checks whether attackers attempt to log in to the device through brute force cracking. |
Device file tampering |
Checks whether files in a specified directory of a device are tampered with. |
Disconnection Analysis
IoTDA help you analyze device disconnection causes by collecting statistics on the disconnection time range and characteristics of disconnected devices.
Disconnection Cause |
Description |
---|---|
Disconnection requested by device |
The device sends an MQTT disconnect packet to IoTDA for disconnection. |
Device heartbeat timed out |
The device does not comply with the MQTT protocol. It sends MQTT heartbeat packets to IoTDA within 1.5 times the configured heartbeat interval. As a result, IoTDA considers that the device connection is invalid and cuts off the connection according to protocol requirements. (Note: The heartbeat interval is specified when the device establishes a connection with IoTDA.) |
Device-platform TCP connection cut off |
IoTDA receives a TCP disconnection packet from the device. As a result, the TCP connection between the device and IoTDA is cut off. |
Device deleted |
The device is deleted from IoTDA, and IoTDA cuts off the connection with the device. |
Device frozen |
The device is frozen on IoTDA, and IoTDA cuts off the connection with the device. |
Connection cut off by IoTDA |
IoTDA cuts off the connection with the device during upgrade. |
Earlier connection cut off |
The device establishes connections with IoTDA repeatedly. IoTDA cuts off the existing connection and retains the new connection. |
Device secret reset |
When the device secret is reset and the connection is manually cut off, IoTDA cuts off the connection with the device. |
Procedure
- Access the IoTDA service page and click Access Console. Click the target instance card.
- In the navigation pane, choose O&M > Anomaly Detection and click Authorize. To use anomaly detection, authorize IoTDA service to perform operations on LTS.
Figure 1 Anomaly detection - Access authorization
- After authorization, Security Checks and Disconnection Analysis pages are available. Click Enable to enable the two functions. Otherwise, they cannot be used.
Figure 2 Anomaly detection - Security checksFigure 3 Anomaly detection - Offline analysis
NOTE:
1. When this function is enabled, IoTDA automatically creates a log group, a log stream, and a data forwarding rule with the data source set to run logs of all resource spaces.
The log group name is {domainName}-device-exception-group, the log stream name is {domainName}-device-exception-stream, and the forwarding rule name is {domainName}-device-exception-rule.
If you delete the rule with the data source set to run logs, this function will be affected. If you disable this function, rules will not be deleted and will be reused when you enable this function again.
2. Pay attention to the storage space occupied by anomaly detection logs. When the free quota (500 MB) is used up, LTS will discard data or continue collecting data after you purchase LTS. You can click Quota in the upper right corner to modify the quota.
- To enable Security Checks, perform the following steps. Otherwise, skip them.
- On the Security Checks tab page, click Security Check Configuration. In the displayed dialog box, click Add.
Figure 4 Anomaly detection - Security check configuration
- On the configuration page, select the resource space and product name to be configured, and enable the corresponding check items as required.
Figure 5 Anomaly detection - Security check item configuration
NOTE:
Memory/CPU usage/Disk space/Battery level checks: The system compares the values reported by the device with the thresholds configured in the check items to determine whether to generate alarms. Abnormal port/Malicious IP address checks: Enter whitelisted ports or IP addresses for checks. The system compares the parameters reported by the device and the configured whitelist members. You can add IP address segments to the whitelist, for example, 192.168.1.10/24.
- On the Security Checks tab page, click Security Check Configuration. In the displayed dialog box, click Add.
- You can click Disable on the corresponding pages to manually disable the security check and disconnection analysis functions, and click Enable to use them again.
Figure 6 Anomaly detection - Disabling the function
NOTE:
- After you enable security checks, IoTDA starts security checks on devices. Security check data of the last seven days can be stored at most. You can search for anomaly records by device ID, resource space, product, check item, and time range, and click the button to check record details.
Figure 7 Anomaly detection - Security check overview
- After you enable disconnection analysis, IoTDA automatically analyzes the causes of device disconnections. Disconnection analysis data of the last seven days can be stored at most. You can search for disconnection data by device ID, resource space, product, cause, and time range, and click the button to check record details.
Figure 8 Anomaly detection - Offline analysis overview
- After you enable security checks, IoTDA starts security checks on devices. Security check data of the last seven days can be stored at most. You can search for anomaly records by device ID, resource space, product, check item, and time range, and click the button to check record details.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot