Network access control method, readable medium, and vehicle-mounted communication terminal

Abstract

The application relates to the field of Internet of Vehicles, and discloses a network access control method, a readable medium and a vehicle-mounted communication terminal. The network access control method comprises the following steps: a vehicle-mounted communication terminal acquires a domain name resolution request message, wherein the domain name resolution request message comprises a first URL address; the vehicle-mounted communication terminal sends the domain name resolution request message to a domain name resolution server under the condition that the first URL address meets a first preset condition; the vehicle-mounted communication terminal receives a domain name resolution response message generated by the domain name resolution server after the domain name resolution server performs domain name resolution on the first URL address, wherein the domain name resolution response message comprises a first IP address; the vehicle-mounted communication terminal adds the first IP address to an IP address white list under the condition that the domain name resolution response message meets a second preset condition; the vehicle-mounted communication terminal acquires a third IP address generated for a user access request; and the third IP address is allowed to access an external server under the condition that the IP address white list contains the third IP address.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a network access control method, a readable medium, and an in-vehicle communication terminal. Background Technology

[0002] With the development of vehicle-to-everything (V2X) technology, more and more passenger vehicles are equipped with in-vehicle communication terminals. These terminals provide vehicles with wireless network communication capabilities to access servers. Depending on the access domain of the service, the T-Box can be equipped with multiple Access Point Names (APNs).

[0003] For example, an in-vehicle communication terminal can be equipped with two APNs, namely APN1 and APN2. APN1 can be used for vehicle control domain communication between the in-vehicle communication terminal and cloud server 1, transmitting vehicle control commands and intelligent vehicle-related data. APN1 has high security requirements, and traffic billing is borne by the manufacturer. APN2 can be used for information service domain communication between the in-vehicle communication terminal and cloud server 2, accessing public Internet infotainment resources. APN2 has low security requirements, and traffic billing is borne by the user.

[0004] Because different access domains have different security levels and involve different traffic billing methods, in order to avoid interference from access data by illegal attacks on access domains and to prevent unauthorized information service domain communication traffic from going through the vehicle control domain to access the Internet, stealing the vehicle manufacturer's traffic and causing economic losses to the vehicle manufacturer, the vehicle communication terminal, as a vehicle networking device, must implement access control on the vehicle terminal APN. Summary of the Invention

[0005] This application provides a network access control method, a readable medium, and a vehicle-mounted communication terminal.

[0006] In a first aspect, embodiments of this application provide a network access control method, comprising: an in-vehicle communication terminal acquiring a domain name resolution request message, the domain name resolution request message including a first URL address; the in-vehicle communication terminal sending a domain name resolution request message to a domain name resolution server when the first URL address meets a first preset condition; the in-vehicle communication terminal receiving a domain name resolution response message generated by the domain name resolution server after performing domain name resolution on the first URL address, wherein the domain name resolution response message includes a first IP address; and the in-vehicle communication terminal adding the first IP address to an IP address whitelist when the domain name resolution response message meets a second preset condition.

[0007] For example, the vehicle-mounted communication terminal obtains a domain name resolution request message, which includes a first URL address. This domain name resolution request message can be generated by the in-vehicle entertainment device based on a user request, or it can be a domain name resolution request message generated by the vehicle-mounted communication terminal itself based on a user request. The vehicle-mounted communication terminal can then parse the domain name resolution request message to obtain the first URL address.

[0008] For example, an in-vehicle communication terminal can send a domain name resolution request message to a domain name resolution server. The domain name resolution server performs domain name resolution on the first URL address in the domain name resolution request message and generates a domain name resolution response message, which includes the first IP address.

[0009] In one possible implementation of the first aspect above, the method further includes: the first preset condition includes: the first URL address conforms to the legal conditions of the URL list pre-set by the car manufacturer, wherein the URL list includes at least one of the following: a URL address whitelist, a URL address blacklist, and an illegal character rule set.

[0010] For example, a URL list can be a URL address whitelist, a URL address blacklist, or a set of rules for illegal characters. For example, a set of rules for illegal characters may include rules that do not allow numbers.

[0011] In some embodiments, the URL list may be a list of URLs pre-set by the vehicle manufacturer before the vehicle leaves the factory; or it may be a list of URLs pre-set by the vehicle manufacturer that the in-vehicle communication terminal obtains from the vehicle manufacturer's server in real time after the vehicle leaves the factory.

[0012] For example, the URL list is a URL address whitelist. The vehicle-mounted communication terminal parses the domain name resolution request message to obtain the URL address. This URL address is the first URL address included in the domain name resolution request message. Based on the URL whitelist, it is determined whether the URL address is in the URL address whitelist. If the URL address exists in the URL address whitelist, it means that the URL address is valid. If the URL address is valid, the vehicle-mounted communication terminal allows the domain name resolution request message to be sent to the domain name resolution server. The domain name resolution server parses the domain name resolution request message to obtain the domain name resolution response message. If the URL address does not exist in the URL address whitelist, it means that the URL address is invalid. If the URL address is invalid, the vehicle-mounted communication terminal discards the domain name resolution request message.

[0013] Understandably, by parsing the domain name resolution request message to obtain the URL address and verifying the validity of the URL address, the vehicle-mounted communication terminal can reduce the attack path for unauthorized access to data and advance the overall attack defense time of the system. This avoids the situation where URL address filtering only applies to unencrypted HTTP services and also avoids the situation where defense actions only occur at the application layer, resulting in a late defense timing.

[0014] In one possible implementation of the first aspect above, the method further includes: when the first URL address meets the first preset condition, the vehicle-mounted communication terminal records the peer information of the device that generates the domain name resolution request message in a mapping table; wherein the peer information includes at least one of the following: the IP address of the device that generates the domain name resolution request message, and the port number of the device that generates the domain name resolution request message.

[0015] In one possible implementation of the first aspect above, the method further includes: when the domain name resolution response message meets the second preset condition, the vehicle-mounted communication terminal adds the first IP address to the IP address whitelist, which includes: when the domain name resolution response message contains peer information in the mapping table, the vehicle-mounted communication terminal adds the first IP address to the IP address whitelist.

[0016] For example, a domain name resolution server performs domain name resolution on a domain name resolution request message and generates a domain name resolution response message. This response message contains the device information that generated the domain name resolution request message. The vehicle-mounted communication terminal can determine the validity of the domain name resolution response message based on the device information in the mapping table.

[0017] For example, if the device generating the domain name resolution request message is an in-vehicle entertainment device, then if the domain name resolution request message is valid, the in-vehicle communication terminal can record the device information of the in-vehicle entertainment device in the mapping table; when the in-vehicle communication terminal obtains the domain name resolution request message, it can match the device information contained in the domain name resolution response message with the device information of the in-vehicle entertainment device in the mapping table, thereby determining whether the domain name resolution response message is valid, that is, determining whether the domain name resolution response message is obtained by resolving the domain name based on a valid domain name resolution request message.

[0018] In one possible implementation of the first aspect above, the method further includes: when the vehicle-mounted communication terminal detects that the IP address whitelist contains an expired second IP address and the expired first IP address is not currently accessing an external server, the vehicle-mounted communication terminal deletes the expired second IP address from the IP address whitelist.

[0019] In one possible implementation of the first aspect above, the method further includes: the vehicle-mounted communication terminal detecting whether the IP address whitelist contains an expired second IP address based on the lifespan of the first IP address in the IP address whitelist.

[0020] For example, the external server could be a content provider server for the in-vehicle system. The in-vehicle communication terminal can periodically check the validity period of each IP address in the IP address whitelist based on the Time To Live (TTL). If the whitelist contains expired IP addresses, the in-vehicle communication terminal checks whether the expired IP address is currently accessing the in-vehicle system content provider server to determine whether to delete the expired IP address from the whitelist. If the expired IP address is not currently accessing the in-vehicle system content provider server, it is deleted from the whitelist. Essentially, the in-vehicle communication terminal periodically monitors whether IP addresses in the IP address whitelist have expired, determines whether the expired IP address is currently in use, and deletes the expired IP address from the whitelist if it is not in use. This ensures that user experience is not affected while deleting expired IP addresses, maintaining network access control performance and preventing subsequent unauthorized IP addresses from accessing the in-vehicle system content provider server.

[0021] In one possible implementation of the first aspect above, the method further includes: the vehicle-mounted communication terminal obtaining a third IP address generated in response to the user access request;

[0022] If the vehicle-mounted communication terminal includes a third IP address in its IP address whitelist, the third IP address is allowed to access the external server.

[0023] For example, an in-vehicle communication terminal can receive domain name resolution response messages sent by a domain name resolution server. These response messages are generated by the domain name resolution server after resolving a domain name resolution request message. The in-vehicle communication terminal can parse these response messages to obtain IP addresses. Based on these IP addresses, the terminal creates an IP address whitelist. Furthermore, the terminal can parse domain name resolution response messages in real time to obtain IP addresses. Therefore, the terminal updates the IP address whitelist in real time with the IP addresses resolved by the domain name resolution server. Based on this whitelist, the terminal determines the IP addresses allowed to access the in-vehicle system content provider server, thereby achieving real-time network access control, preventing unauthorized IP addresses from accessing the content provider server, and improving the granularity of detecting unauthorized access data.

[0024] In one possible implementation of the first aspect above, the method further includes: the vehicle communication terminal is a vehicle networking terminal box.

[0025] Secondly, embodiments of this application provide a readable medium storing instructions that, when executed on a vehicle-mounted communication terminal, cause the vehicle-mounted communication terminal to perform any of the network access control methods described in the first aspect and various possible implementations of the first aspect.

[0026] Thirdly, embodiments of this application provide a vehicle-mounted communication terminal, including: a memory for storing instructions executed by one or more processors of the vehicle-mounted communication terminal, and a processor, which is one of the processors of the vehicle-mounted communication terminal, for executing the first aspect and any of the various possible implementations of the first aspect of the network access control method. Attached Figure Description

[0027] Figure 1 According to some embodiments of this application, a schematic diagram of a vehicle-to-everything (V2X) scenario is shown;

[0028] Figure 2 According to some embodiments of this application, a schematic diagram of a network access control method is shown.

[0029] Figure 3 According to some embodiments of this application, a schematic diagram of another network access control method is shown;

[0030] Figure 4 According to some embodiments of this application, a flowchart of a network access control method is shown;

[0031] Figure 5 According to some embodiments of this application, a schematic diagram of another network access control method is shown;

[0032] Figure 6 According to some embodiments of this application, an interactive flowchart of network access control based on access data from an IVI is shown;

[0033] Figure 7 According to some embodiments of this application, an interactive flowchart of network access control based on access data from the internal service module of a T-Box is shown;

[0034] Figure 8 According to some embodiments of this application, an application diagram of a DNS relay module based on the prior art is shown;

[0035] Figure 9 According to some embodiments of this application, a schematic diagram of the composition structure of a DNS relay module is shown;

[0036] Figure 10 According to some embodiments of this application, an interaction flowchart of the various units of a DNS relay module is shown when the DNS relay module performs domain name resolution request message processing and forwarding.

[0037] Figure 11 According to some embodiments of this application, an interaction flowchart of the various units of a DNS relay module is shown when the DNS relay module performs domain name resolution response message processing and forwarding.

[0038] Figure 12 According to some embodiments of this application, a schematic diagram of the composition structure of a firewall rule management unit is shown;

[0039] Figure 13 According to some embodiments of this application, a flowchart is shown of a firewall configuration rule setting of an outbound firewall module by a firewall rule management unit;

[0040] Figure 14 According to some embodiments of this application, a flowchart is shown of a firewall configuration rule setting process for an outbound firewall module by a firewall rule management unit;

[0041] Figure 15 According to some embodiments of this application, a schematic block diagram of the hardware structure of an in-vehicle communication terminal is shown. Detailed Implementation

[0042] The illustrative embodiments of this application include, but are not limited to, network access control methods, readable media, and electronic devices.

[0043] Before disclosing the details of the specific implementation schemes of this application, for ease of understanding, the technical terms involved in the embodiments of this application are explained by way of example:

[0044] APN: A network access technology, a parameter that must be configured when using in-vehicle devices to access the internet. It determines which access method the in-vehicle device uses to access the network. In-vehicle devices can access many types of external networks, such as the Internet, Wireless Application Protocol (WAP) websites, corporate intranets, and industry-specific private networks (e.g., car manufacturer networks). Different access points have different access ranges and methods. The network side needs to know which network the mobile terminal will access after activation to assign the appropriate Internet Protocol (IP) segment. This is where the APN comes in; in other words, the APN determines which access method the in-vehicle device uses to access which network.

[0045] A Uniform Resource Locator (URL) is a method of identifying the address of web pages and other resources on the Internet. It's a naming convention specifically designed to identify the location of resources on the Internet; the web page address we usually refer to is the URL. A URL is a concise representation of the location and access method of a resource obtainable from the Internet, and it's the standard address of resources on the Internet. Every file on the Internet has a unique URL, which contains information indicating the file's location and how the browser should handle it.

[0046] The Domain Name System (DNS) primarily consists of domain name resolvers and domain name servers. A domain name server is a server that stores the domain names and corresponding IP addresses of all hosts on the network and has the function of converting domain names into IP addresses. A domain name must correspond to one IP address; an IP address can have multiple domain names, but an IP address does not necessarily have a domain name. The DNS adopts a hierarchical structure similar to a directory tree. Domain name servers are typically the server side in a client / server model, and they mainly take two forms: primary servers and forwarding servers. The process of mapping a domain name to an IP address is called "domain name resolution." In simple terms, the role of DNS is to resolve a given string of domain name addresses into uniquely identifiable IP addresses on the Internet for communication.

[0047] Domain name resolution messages include domain name resolution request messages and domain name resolution response messages. In the DNS protocol, all communication is transmitted through domain name resolution messages. A domain name resolution message consists of a 12-byte header and four variable-length fields (question, answer, authority, and additional). The header indicates whether the message is a domain name resolution request or response message. The Question segment contains information requesting the domain name server. The answer, authority, and additional segments all use the same format called resource records (RR). The answer segment contains resource records that directly answer the question segment. The authority segment contains RRs (basically NS records) that can point to authoritative servers. The additional segment contains information related to the request but not a direct answer to the question (such as A records corresponding to NS and MX records). When constructing a DNS request packet, the requested domain name and request class should be added to the Question segment according to the DNS packet format requirements, and then the header is added to encapsulate it into a domain name resolution message.

[0048] To make the purpose, technical solution, and advantages of this application clearer, the following is in conjunction with... Figures 1 to 15 The technical solution of this application is described in detail.

[0049] Figure 1 According to an embodiment of this application, a schematic diagram of a vehicle-to-everything (V2X) scenario is shown, which includes: a vehicle 40, at least one electronic device 20, and at least one server 30; the vehicle 40 is equipped with an on-board device 10, which can communicate with the electronic device 20 and / or the server 30 via a network.

[0050] like Figure 1 As shown, electronic device 20 can remotely control the vehicle or transmit data via wired or wireless communication with vehicle-mounted device 10. For example, electronic device 20-1 can remotely monitor and operate the vehicle, while electronic device 20-2 can share data.

[0051] like Figure 1 As shown, server 30-1 or server 30-2 can be a telematics service provider (TSP) server that provides multimedia information, navigation and other in-vehicle services. Server 30-3 can be a domain name resolution server. Domain name resolution server 30-3 has domain name resolution function and can parse domain name resolution request messages to obtain IP addresses.

[0052] like Figure 1 As shown, the in-vehicle device 10 may include an in-vehicle communication terminal 11 and an in-vehicle infotainment (IVI) device 12. The in-vehicle communication terminal 11 can communicate with the IVI 12 via wired or wireless means.

[0053] In some embodiments, the vehicle-mounted communication terminal 11 can be used for network communication between the vehicle-mounted device 10 and server 30-1 or server 30-2, providing entertainment and communication services, vehicle control services, etc., for the vehicle-mounted device 10. For example, the vehicle-mounted communication terminal 11 can provide the vehicle-mounted device 10 with entertainment and communication services including data monitoring, real-time navigation, web browsing, and direct use of vehicle applications (apps); the vehicle-mounted communication terminal 11 can also provide the vehicle-mounted device 10 with vehicle control services including driving data collection, driving trajectory recording, vehicle fault monitoring, remote vehicle query and control (locking and unlocking, air conditioning control, window control, engine torque limiting, engine start-stop), driving behavior analysis, etc. The vehicle-mounted communication terminal 11 can also implement access control on the vehicle-mounted APN to prevent unauthorized access to data and servers. The vehicle-mounted communication terminal 11 can be a Telematics Box (T-Box) or a Telematics Control Unit (TCU). It is understood that this application does not specifically limit the vehicle-mounted communication terminal 11 according to actual application needs. The following section uses the vehicle-mounted communication terminal 11 as a T-box as an example to illustrate the network access control scheme of this application.

[0054] As mentioned earlier, when the vehicle-mounted device 10 accesses the server 30, interference from unauthorized access data often occurs, such as unauthorized information service domain communication traffic passing through the vehicle control domain to access the internet, stealing the vehicle manufacturer's traffic, and causing economic losses to the vehicle manufacturer. In order to implement access control for the vehicle-mounted APN, this application first introduces a network access control method. This method uses T-Box11 to configure firewall rules to filter access data, allowing legitimate access data to pass through and discarding illegitimate access data. T-Box11 also authenticates the source of access data and filters access data based on the authentication results to achieve network access control.

[0055] Figure 2 According to an embodiment of this application, a schematic diagram of a network access control method is shown.

[0056] like Figure 2 The vehicle-mounted device 10 shown can generate access data to access the server 30 based on user requests. Access data includes, but is not limited to, domain name resolution request messages containing URL addresses and IP addresses.

[0057] Specifically, for example, such as Figure 2 (a) The IVI 12 of the vehicle-mounted device 10 can detect access data generated based on user requests to access server 30. The IVI 12 can send the access data to T-box 11, and T-box 11 forwards the access data to server 30 to request access to server 30. For example, as Figure 2 As shown in (b), the T-Box 11 of the vehicle-mounted device 10 can also detect access data generated based on user requests to access server 30. The T-box 11 itself can send the access data to server 30 to request access to server 30.

[0058] Specifically, such as Figure 2 As shown, T-Box11 includes an inbound firewall module 110, an internal service module 111, a gateway module 114, and an outbound firewall module 113.

[0059] Inbound firewall module 110: Used to filter access data sent from IVI12 to server 30 via T-box11 and discard illegal access data. The access data includes, but is not limited to, URL addresses, domain name resolution request messages corresponding to the URL addresses, and IP addresses corresponding to the URL addresses.

[0060] Outbound firewall module 113: Used to filter access data sent from IVI12 to server 30 via T-box11, and / or access data sent from T-box11's internal service module 111 to server 30-1, and to discard illegal access data.

[0061] Internal service module 111: Used to detect access data generated by access server 30-1 based on user requests.

[0062] Gateway module 114: Used to authenticate the IVI12 and / or internal service module 111 of access server 30-1 or server 30-2, and to connect access data to APN1 or APN2 to access server 30-1 or service 30-2 based on the authentication result.

[0063] For example, such as Figure 2 As shown in (a), the IVI12 detects access data generated based on a user request to access server 30-1 or server 30-2. Based on this access data, the IVI12 can access server 30-1 or server 30-2 to provide functions such as audio-visual entertainment, web search, vehicle control, and navigation to the in-vehicle device 10. This access data includes, but is not limited to, domain name resolution request messages containing URL addresses and the IP addresses of these domain name resolution request messages.

[0064] like Figure 2As shown in (a), IVI12 needs to send the access data to T-Box11 first, and then T-Box11 forwards it to server 30-1 or server 30-2 to enable access to server 30-1 or server 30-2. After receiving access data from IVI12, T-Box11 can control access to the APN through its inbound firewall module 110, gateway module 114, and outbound firewall module 113. For example, T-Box11 can configure firewall rules in the inbound firewall module 110 and outbound firewall module 113 to filter access data passing through them, allowing legitimate access data to pass and discarding illegitimate access data. T-Box11 can also authenticate the IVI12 of access server 30-1 or server 30-2 through the gateway module 114, and connect the access data sent by IVI12 to APN1 or APN2 to access server 30-1 or server 30-2 based on the authentication result.

[0065] For example, such as Figure 2 As shown in (b), the internal service module 111 of T-Box11 can detect the access data of access server 30-1 generated based on user requests, and provide vehicle-mounted equipment 10 with functions such as remote vehicle query and control.

[0066] like Figure 2 As shown in (b), T-Box 11 can use the access data of access server 30 generated based on user requests detected by the internal service module 111 to perform access control on the APN through the gateway module 114 and the outbound firewall module 113. For details on the access control, please refer to [link / reference needed]. Figure 2 The description of (a) will not be repeated here.

[0067] However, by Figure 2 As can be seen from the network access control method illustrated, the T-Box11 needs to integrate a gateway module 114 and also needs to introduce functions such as negotiation, authentication, and communication connection maintenance. The IVI12 and / or the T-box11 itself also need to introduce corresponding access authentication functions, resulting in high complexity. Furthermore, this process requires pre-obtaining port information or network information of the IVI12 and / or the internal service module 111, and pre-configuring the gateway module 114 program based on this information, thus increasing the cost of implementing this process.

[0068] This application also introduces another network access control method. This method uses a T-Box11 to configure firewall rules to filter access data, allowing legitimate access data to pass while discarding illegitimate access data, thereby achieving network access control. The configured firewall rules mainly include: using a FORWARD chain to control the forwarding path of access data and prevent unauthorized forwarding; filtering IP addresses to control the IP addresses accessible by different APNs within a trusted whitelist range; and filtering URL addresses at the application layer to filter accessible URL addresses. It is understandable that, compared to... Figure 2 The process of the vehicle-mounted device 10 accessing server 30-1 or server 30-2 is made more efficient by forwarding the access data to server 30-1 or server 30-2 through the routing module 112, thereby reducing the maintenance cost of access control.

[0069] Figure 3 According to an embodiment of this application, a schematic diagram of another network access control method is shown.

[0070] Specifically, such as Figure 3 As shown, T-Box 11 includes an inbound firewall module 110, an internal service module 111, a routing module 112, and an outbound firewall module 113. The contents of the inbound firewall module 110, internal service module 111, and outbound firewall module 113 are described in [reference needed]. Figure 2 The description of that will not be repeated here.

[0071] Routing module 112: Used to forward access data generated by IVI12 and / or T-box11 itself to server 30-1 or server 30-2 according to the destination address of the access data.

[0072] For example, such as Figure 3 As shown in (a), the IVI12 detects access data generated based on a user request to access server 30-1 or server 30-2. Based on this access data, the IVI12 can access server 30-1 or server 30-2 to provide functions such as audio-visual entertainment, web search, vehicle control, and navigation to the in-vehicle device 10. This access data includes, but is not limited to, domain name resolution request messages containing URL addresses and IP addresses.

[0073] like Figure 3As shown in (a), IVI12 needs to send the access data to T-Box11 first, and then T-Box11 forwards it to server 30-1 or server 30-2 to enable access to server 30-1 or server 30-2. After receiving access data from IVI12, T-Box11 can control APN access through inbound firewall module 110, routing module 112, and outbound firewall module 113. For example, T-Box11 can configure FORWARD chains in inbound and outbound firewall modules 110 and 113 to control the forwarding path of access data and prevent unauthorized forwarding. T-Box11 can also configure firewall rules in inbound and outbound firewall modules 110 and 113 to filter access data passing through them, allowing legitimate access data to pass and discarding illegitimate access data. For example, by filtering IP addresses, the accessible IP addresses of different APNs can be controlled within a trusted whitelist; by filtering URL addresses, accessible URL addresses can be filtered at the application layer. T-Box11 can also redirect access data from IVI12 to server 30-1 or server 30-2 via routing module 112.

[0074] For example, such as Figure 3 As shown in (b), the internal service module 111 of T-Box11 can detect the access data of access server 30-1 generated based on user requests, and provide vehicle-mounted equipment 10 with functions such as remote vehicle query and control.

[0075] like Figure 3 As shown in (b), T-Box 11 can control access to the APN by passing the access data of access server 30-1 generated based on user requests detected by the internal service module 111 through the routing module 112 and the outbound firewall module 113. For details on the access control, please refer to [link / reference needed]. Figure 3 The description of (a) will not be repeated here.

[0076] Understandably, T-box11's routing module 112 can route access data from IVI12 and / or from T-box11 itself to APN1 or APN2 to achieve targeted access to server 30-1 or server 30-2. Furthermore, T-box11 can filter and legally forward access data by configuring FORWARD chains or firewall rules in the inbound firewall module 110 and outbound firewall module 113. However, in practical applications, T-box11's granularity in controlling the legality of access data based on FORWARD chains is too high; it can only control the legality of the forwarding path, not the legality of the source of traffic entering the interface. Moreover, because IP addresses are time-varying, IP address filtering is a dynamic process that cannot be pre-configured, and T-box11's routing module 112 does not participate in the connection establishment process, making it impossible to determine the legal range of IP addresses. Furthermore, URL address filtering only applies to unencrypted HTTP services, and the defense action occurs at the application layer, resulting in a late defense timing.

[0077] To address the aforementioned technical issues, this application proposes a network access control method, primarily applied to in-vehicle communication terminals. T-box 11 can obtain domain name resolution request messages, which contain URL addresses. T-box 11 can verify the URL addresses in the domain name resolution request messages based on a preset URL list. Only if the URL address is valid will the domain name resolution request message be sent to the domain name resolution server 30-3. It is understood that by parsing the domain name resolution request messages to obtain the URL addresses and verifying their validity, T-box 11 can reduce attack paths for unauthorized data access, advance the overall system's attack defense timeline, avoid the limitation of URL address filtering only applying to unencrypted HTTP services, and prevent defense actions from occurring only at the application layer, resulting in delayed defense.

[0078] Furthermore, T-box11 can receive domain name resolution response messages sent by domain name resolution server 30-3. These response messages are generated by domain name resolution server 30-3 through domain name resolution of the domain name resolution request message. T-box11 can parse these response messages to obtain IP addresses. Based on these IP addresses, T-box11 creates an IP address whitelist. Since T-box11 can parse domain name resolution response messages in real time to obtain IP addresses, it updates the IP addresses resolved by domain name resolution server 30-3 to the IP address whitelist in real time. Based on this whitelist, T-box11 determines the IP addresses allowed to access server 30-1 or server 30-2, thereby achieving real-time network access control, preventing unauthorized IP addresses from accessing server 30-1 or server 30-2, and improving the granularity of detecting unauthorized access data.

[0079] Furthermore, T-box11 can periodically check the expiration date of each IP address in the IP address whitelist based on their Time To Live (TTL). If an expired IP address is found in the whitelist, T-box11 checks whether that expired IP address is currently accessing server 30-1 or server 30-2 to determine whether to remove it. If the expired IP address is not currently accessing server 30-1 or server 30-2, it is removed from the whitelist. In essence, by periodically monitoring the expiration of IP addresses in the whitelist and determining whether they are currently in use, T-box11 removes expired IP addresses from the whitelist if they are not in use. This ensures that user experience is not affected while still maintaining network access control performance and preventing unauthorized IP addresses from accessing server 30-1 or server 30-2.

[0080] Figure 4 According to an embodiment of this application, a flowchart of network access control is shown, such as... Figure 4 As shown, it specifically includes:

[0081] S401: T-box11 obtains a domain name resolution request message, wherein the domain name resolution request message includes a URL address domain name resolution request message.

[0082] In some embodiments, T-box11 can obtain domain name resolution request messages from IVI12, or it can obtain domain name resolution request messages generated by itself.

[0083] S402: T-box11 parses the domain name resolution request message to obtain the URL address.

[0084] S403: T-box11 determines whether the parsed URL address is valid based on the pre-saved URL list; if the URL address is invalid, proceed to step S404; if the URL address is valid, proceed to step S405.

[0085] In some embodiments, the URL list can be a URL address whitelist, a URL address blacklist, or a rule used to determine whether a URL address contains illegal characters, such as a rule that a URL address is not allowed to contain numbers.

[0086] In some embodiments, the URL list may be a list of URLs pre-set by the vehicle manufacturer before the vehicle 40 leaves the factory; or it may be a list of URLs pre-set by the vehicle manufacturer that the T-box 11 obtains in real time from the vehicle manufacturer's server after the vehicle 40 leaves the factory.

[0087] For example, the URL list is a whitelist of URL addresses. T-box11 parses the domain name resolution request message to obtain the URL address. Based on the URL whitelist, it determines whether the URL address is in the whitelist. If the URL address exists in the whitelist, it means the URL address is valid. If the URL address is valid, T-box11 allows the domain name resolution request message to be sent to the domain name resolution server 30-3. The domain name resolution server 30-3 parses the domain name resolution request message to obtain the domain name resolution response message. If the URL address does not exist in the whitelist, it means the URL address is invalid. If the URL address is invalid, T-box11 discards the domain name resolution request message. The following text describes in detail the processing and forwarding of domain name resolution request messages by T-box11, which will not be repeated here.

[0088] S404: T-box11 dropped the domain name resolution request message.

[0089] S405: T-box11 records the peer information in the mapping table.

[0090] For example, if the URL address obtained through resolution is valid, the peer information is recorded in the mapping table. This peer information is the device information that generated the domain name resolution request message. The peer information in the domain name resolution response message includes, but is not limited to, the IP address and port number of the device that generated the access data.

[0091] S406: T-box11 retrieves the domain name resolution response message, which contains the IP address.

[0092] For example, a domain name resolution response message can be generated by domain name resolution server 30-3 resolving the domain name address in the domain name resolution request message, and the domain name resolution response message contains the device information that generated the domain name resolution request message.

[0093] S407: T-box11 determines the validity of the domain name resolution response message based on the peer information. If the domain name resolution response message is invalid, proceed to step S408; if the domain name resolution response message is valid, proceed to step S409.

[0094] For example, the domain name resolution server 30-3 performs domain name resolution on the domain name resolution request message and generates a domain name resolution response message. This response message contains the device information that generated the domain name resolution request message. The T-box 11 can determine, based on the device information in the mapping table, whether the domain name resolution response message obtained in step S406 is a domain name resolution response message generated from the valid domain name resolution request message in step S405.

[0095] For example, if the device generating the domain name resolution request message is IVI12, then if the domain name resolution request message is valid, T-box11 can record the device information of IVI12 in the mapping table. When T-box11 receives the domain name resolution request message, it can match the device information contained in the domain name resolution response message with the device information of IVI12 in the mapping table to determine whether the domain name resolution response message is valid, i.e., whether the domain name resolution response message was obtained based on a valid domain name resolution request message. S408: T-box11 discards the domain name resolution response message.

[0096] S409: T-box11 resolves the domain name resolution response message, obtains the IP address, and creates an IP address whitelist based on the IP address obtained from the resolution.

[0097] For example, T-box can record the resolved IP addresses and their corresponding information in a list of entries. The IP addresses recorded in this list are called the IP address whitelist. This IP address whitelist can be used to set outbound firewall configuration rules so that T-box only allows IP addresses in the IP address whitelist to access the server.

[0098] In the embodiments of this application, when both the domain name resolution request message and the domain name resolution response message are valid, the T-box11 can parse the domain name resolution response message to obtain the IP address and save the IP address in the IP address whitelist. The IP address whitelist can be used to set outbound firewall configuration rules so that the T-box11 only allows IP addresses in the IP address whitelist to access the server.

[0099] S410: T-box11 filters IP addresses used to access server 30-1 or server 30-2 based on an IP address whitelist.

[0100] Understandably, according to Figure 4 The described network access control method can control APN access during DNS packet resolution. Furthermore, T-box11 updates the IP address resolved by domain name resolution server 30-3 to the IP address whitelist in real time. Based on the IP address whitelist, T-box11 determines the IP address allowed to access server 30-1 or server 30-2, thereby achieving real-time network access control, preventing unauthorized IP addresses from accessing server 30-1 or server 30-2, and improving the granularity of detecting unauthorized access data.

[0101] In other embodiments of this application, the network access control domain name resolution response message can be implemented by the various modules in the structure of the T-box 11. Figure 4 Describes the network access control process. For example, such as... Figure 5 As shown, T-Box 11 includes an inbound firewall module 110, an internal service module 111, a routing module 112, an outbound firewall module 113, and a DNS relay module 115. The contents of the inbound firewall module 110, internal service module 111, outbound firewall module 113, and routing module 112 are described below. Figure 3 The description of that will not be repeated here.

[0102] DNS relay module 115: used to parse domain name resolution request messages and / or domain name resolution response messages, to perform legality judgment on the parsed domain name resolution request messages, and / or to perform legality judgment on the domain name resolution response messages; furthermore, DNS relay module 115 can also use the IP address obtained from the parsed domain name resolution response messages for outbound firewall rule configuration of outbound firewall module 113.

[0103] Compared to Figure 3 The DNS access control method shown in (a) is as follows: Figure 5 As shown in (a), IVI12 can send access data to T-Box11. After passing through the inbound firewall module 110 of T-Box11, the inbound firewall module 110 can set outbound firewall rules to only allow the IP address in the access data to be forwarded to the routing module 112, and redirect the domain name resolution request message in the access data to the DNS relay module 115, so that the DNS relay module 115 can receive the domain name resolution request message and verify the legality of the domain name resolution request message.

[0104] For example, such as Figure 5 As shown in (a), IVI12 needs to send the access data to T-Box11 first, and then T-Box11 forwards it to server 30-1 to enable access to server 30-1. The access data includes: a domain name resolution request message containing the URL address and the IP address.

[0105] Specifically, for example, the DNS relay module 115 of T-Box11 can perform legality verification on the domain name resolution request messages in the access data; it can also perform legality verification on the domain name resolution response messages sent by the domain name resolution server 30-3; it can also resolve the legal domain name resolution response messages to obtain IP addresses and configure the obtained IP addresses in the IP address whitelist of the outbound firewall module 113; when the IP addresses in the access data pass through the outbound firewall module 113, the IP addresses in the access data can be filtered according to the IP address whitelist, and only legal IP addresses are allowed to access server 30-1 or server 30-2.

[0106] For example, such as Figure 5 As shown in (b), the internal service module 111 of T-Box11 first sends the access data to the outbound firewall module 113. The outbound firewall module 113 can redirect the domain name resolution request packets in the access data to the DNS relay module 115. The internal service module 111 of T-Box11 can also send the IP address in the access data to server 30-1 via the routing module 112 and the outbound firewall module 113. When the IP address in the access data passes through the outbound firewall module 113, it can filter the IP address in the access data according to the IP address whitelist, allowing only legitimate IP addresses to access server 30-1. For specific access control details, please refer to [link / reference]. Figure 5 The description of (b) will not be repeated here.

[0107] like Figure 5 As shown, the T-box 11 of the vehicle-mounted device 10 not only integrates the routing module 112, but also the DNS relay module 115. The DNS relay module 115 of the T-box 11 can perform legality verification on the domain name resolution request message and the domain name resolution response message. The DNS relay module 115 of the T-box 11 can also control the outbound firewall module 113 to filter IP addresses from the internal service module 111 and / or from the IVI 12, ensuring that only legitimate IP addresses can access the server 30-1.

[0108] Understandably, compared to Figure 3The process of the vehicle-mounted device 10 accessing the server 30-1 involves obtaining the resolved legitimate IP address in real time through the DNS relay module. This updates the whitelist of IP addresses accessing different APNs, thereby improving the granularity of network access control detection and enhancing the real-time nature of legitimacy verification and defense effectiveness. The following section provides a detailed description of the legitimacy verification of access data by the DNS relay module 115, which will not be elaborated upon here.

[0109] Figure 5 (a) This explanation primarily uses the example of IVI12 generating an IP address based on a user request and accessing server 30-1 via T-Box11. It's understandable that IVI12 can also generate an IP address based on a user request and access server 30-2 via T-Box11, and IVI12 can also generate an IP address based on a user request and access other servers (e.g., server 30-n) via T-Box11. The following explanation mainly uses the example of IVI12 generating an IP address based on a user request and verifying the validity of the IP address accessing server 30-1 via T-Box11. The network access control process of IVI12 accessing other servers via T-Box11 based on user requests can be found in the section on the network access control process of IVI12 generating access data based on user requests and accessing server 30-1 via T-Box11; it will not be elaborated upon here.

[0110] Figure 5 (b) This explanation primarily uses the example of T-Box11's internal service module 111 generating an IP address to access server 30-1 based on a user request. It is understood that T-Box11's internal service module 111 can also access server 30-2 based on a user request, and IVI12 can access other servers (e.g., server 30-n) based on a user request. The following explanation mainly uses T-Box11's internal service module 111 generating an IP address to access server 30-1 based on a user request. The network access control process for T-Box11's internal service module 111 accessing other servers based on a user request can be found in the content regarding the network access control process for T-Box11's internal service module 111 generating an IP address to access server 30-1 based on a user request; it will not be elaborated upon here.

[0111] based on Figure 5 (a) The network access control method based on the IP address from IVI12 is described in detail below through the interaction process between IVI12, the various modules of T-box11, server 30-1 and domain name resolution server 30-3.

[0112] Figure 6According to an embodiment of this application, an interactive flowchart of network access control based on access data from an IVI12 is shown. For example... Figure 6 As shown, it specifically includes:

[0113] S601: IVI12 generates a domain name resolution request message based on the user's request, wherein the domain name resolution request message includes a URL address.

[0114] In some embodiments, users can enter the URL address to be accessed on the IVI12 display screen, for example, by searching for the URL address to be accessed in the search box of the IVI12 display interface; users can also click the application icon on the IVI12 display interface to request access to the URL address of the corresponding application, for example, the "Map" application installed on the IVI12; users can also generate corresponding URL addresses on the IVI12 based on driving trajectory records, vehicle fault monitoring, etc., and the IVI12 will encapsulate the URL address into a domain name resolution request message.

[0115] S602: IVI12 sends the domain name resolution request message to the inbound firewall module 110 of T-box11.

[0116] S603: The inbound firewall module 110 of the T-box 11 sends the domain name resolution request message to the DNS relay module 115.

[0117] In some embodiments, during firewall initialization, the inbound firewall module 110 of T-box 11 can configure outbound firewall rules to only allow IP addresses in the access data to be forwarded to the routing module 112, and redirect domain name resolution request packets in the access data to the DNS relay module 115, thereby enabling the DNS relay module 115 to receive domain name resolution request packets. For example, the inbound firewall module 110 of T-box 11 redirects domain name resolution request packets from IVI 12 to the DNS relay module 115 using Destination Network Address Translation (DNAT) technology.

[0118] S604: The DNS relay module 115 of T-box11 processes and forwards domain name resolution request messages.

[0119] In some embodiments, the DNS relay module 115 of T-box 11 can first parse the domain name resolution request message to obtain the URL address; the DNS relay module 115 of T-box 11 determines whether the obtained URL address is valid according to the pre-saved URL list. If the obtained URL address is valid, the DNS relay module 115 of T-box 11 records the peer information of the IVI 12 that sent the domain name resolution request message in the mapping table, and forwards the domain name resolution request message to the domain name resolution server 30-3. The domain name resolution server 30-3 parses the domain name resolution request message and obtains the domain name resolution response message.

[0120] In some embodiments, after receiving a domain name resolution request message from IVI12, the DNS relay module 115 of T-box11 records the peer information of IVI12 in a mapping table for use in verifying the validity of the domain name resolution response message below. The peer information includes, but is not limited to, IP address and port number information.

[0121] In some embodiments, in order to determine whether the currently acquired domain name resolution request message can be forwarded to the domain name resolution server 30-3, the DNS relay module 115 of T-box 11 can first parse the domain name resolution request message to obtain the URL address, and compare the obtained URL address with a pre-set URL list; wherein, the URL list can be a whitelist or a blacklist.

[0122] For example, the URL list is a URL address whitelist. The DNS relay module 115 of T-box11 parses the domain name resolution request message to obtain the URL address. Based on the URL whitelist pre-provided by the industry (e.g., a car manufacturer) and stored in memory, the DNS relay module 115 determines whether the URL address is in the URL address whitelist. If the URL address exists in the URL address whitelist, it means that the URL address is valid. In this case, the DNS relay module 115 of T-box11 allows the domain name resolution request message to be sent to the domain name resolution server 30-3. If the URL address does not exist in the URL address whitelist, it means that the URL address is invalid. In this case, the DNS relay module 115 of T-box11 discards the domain name resolution request message. The following text describes in detail the processing and forwarding of the domain name resolution request message by the DNS relay module 115 of T-box11, which will not be repeated here.

[0123] S605: The DNS relay module 115 of T-box11 sends a valid domain name resolution request message to the domain name resolution server 30-3.

[0124] S606: Domain Name Resolution Server 30-3 performs domain name resolution on the URL address contained in the domain name resolution request message and generates a domain name resolution response message, which includes the IP address.

[0125] S607: Domain name resolution server 30-3 sends the domain name resolution response message to DNS relay module 115 of T-box 11.

[0126] S608: The DNS relay module 11 of T-box 11 processes and forwards domain name resolution response messages.

[0127] In some embodiments, the DNS relay module 11 of T-box 11 can determine whether the domain name resolution response message is valid based on the peer information of IVI 12 recorded in step S604. If the domain name resolution response message is valid, the domain name resolution response message is parsed to obtain the IP address, and the IP address and the information corresponding to the IP address are recorded in the entry list. The IP address recorded in the entry list is the IP address whitelist, which can be used to set outbound firewall configuration rules so that the outbound firewall module 113 only allows IP addresses in the IP address whitelist to access server 30-1.

[0128] For example, the DNS relay module 115 of T-box11 can first determine whether the domain name resolution response message is valid. If the domain name resolution response message is invalid, the DNS relay module 115 of T-box11 will discard the domain name resolution response message. If the domain name resolution response message is valid, it will be forwarded to IVI12. At the same time, the domain name resolution response message will be parsed to obtain the IP address. Based on the obtained IP address, outbound firewall configuration rules will be set for IP address filtering in step S613 below. The processing and forwarding of the domain name resolution response message will be described in detail below, and will not be repeated here.

[0129] S609: The DNS relay module 11 of T-box11 sets the firewall configuration rules of the outbound firewall module 113 based on the resolved domain name resolution response message. The following text describes in detail the configuration of the outbound firewall policy by the DNS relay module 11 of T-box11, which will not be repeated here.

[0130] S610: The DNS relay module 115 of T-box 11 sends the domain name resolution response message to IVI 12.

[0131] Understandable, Figure 6The network access control method based on access data from IVI12 is executed in the order of steps S609 to S610. In other embodiments of this application, the execution order of steps S609 to S610 can also be other orders. For example, the DNS relay module 115 of T-box11 can first send the domain name resolution response message to IVI12 and then configure the outbound firewall policy; the DNS relay module 115 of T-box11 can also send the domain name resolution response message to IVI12 and configure the outbound firewall policy at the same time. The specific execution order is not limited in this application.

[0132] S611: IVI12 generates an IP address domain name resolution response message based on the user's request.

[0133] S612: IVI12 sends the IP address to the outbound firewall module 113 of T-box11.

[0134] In some embodiments, when IVI12 sends an IP address to the outbound firewall module 113 of T-box11, it needs to pass through the inbound firewall module 110 and the routing module 112.

[0135] S613: The outbound firewall module 113 of T-box11 determines the validity of the received IP address. If the IP address is valid, step S614 is executed.

[0136] In some embodiments, the outbound firewall module 113 of T-box 11 can execute step S614 if the IP address is valid, and discard the invalid IP address if the IP address is invalid.

[0137] S614: The outbound firewall module 113 of T-box11 sends the legitimate IP address to server 30-1.

[0138] In other embodiments of this application, such as Figure 5 As shown in (b), based on the access data from the internal service module 111 of T-Box11, the DNS relay module 115 of T-box11 can perform legality verification on the domain name resolution request message and the domain name resolution response message. The DNS relay module 115 of T-box11 can also control the outbound firewall module 113 to filter the IP addresses from the internal service module 111 to ensure that only legitimate IP addresses can access server 30-1.

[0139] based on Figure 5(b) The network access control method based on access data from the internal service module of T-Box11. The following describes in detail the execution process of another network access control method of this application through the interaction process between the internal service module 111, routing module 11, outbound firewall module 113, DNS relay module 115 of T-box11, server 30-1 and domain name resolution server 30-3.

[0140] Figure 7 An embodiment of this application illustrates an interactive flowchart of network access control based on access data from the internal service module 111 of T-Box 11. For example... Figure 7 As shown, it specifically includes:

[0141] S701: The internal service module 111 of T-Box11 generates a domain name resolution request message based on the user request, wherein the domain name resolution request message includes a URL address.

[0142] For example, when a user controls the vehicle, the internal service module 111 of the T-Box11 can generate a domain name resolution request message based on the detected user control, wherein the domain name resolution request message includes a URL address.

[0143] S702: The internal service module 111 of T-box11 sends the domain name resolution request message to the inbound firewall module 110 of T-box11.

[0144] S703: The inbound firewall module 110 of T-box11 sends the domain name resolution request message to the DNS relay module 115; for details, please refer to the description of step S603, which will not be repeated here.

[0145] S704: The DNS relay module 115 of T-box 11 processes and forwards domain name resolution request messages. For details, please refer to the description in step S604, which will not be repeated here.

[0146] S705: The DNS relay module 115 of T-box11 sends a valid domain name resolution request message to the domain name resolution server 30-3.

[0147] S706: Domain Name Resolution Server 30-3 performs domain name resolution on the URL address in the domain name resolution request message and obtains the domain name resolution response message.

[0148] S707: Domain name resolution server 30-3 sends the domain name resolution response message to the DNS relay module 115 of T-box 11.

[0149] S708: The DNS relay module 115 of T-box 11 processes and forwards the domain name resolution response messages. For details, please refer to the description in step S608, which will not be repeated here.

[0150] S709: The DNS relay module 11 of T-box 11 sets the firewall configuration rules of the outbound firewall module 113 based on the resolved domain name resolution response message.

[0151] S710: The internal service module 111 of T-box11 parses the domain name resolution response message to obtain the IP address corresponding to the URL address.

[0152] Understandable, Figure 7 The network access control method based on access data from the internal service module 111 of T-Box 11 is executed in the order of steps S709 to S710. In other embodiments of this application, the execution order of steps S709 to S710 can also be other orders. For example, the DNS relay module 115 of T-box 11 can first send the domain name resolution response message to the internal service module 111 and then configure the outbound firewall policy; the DNS relay module 115 of T-box 11 can also send the domain name resolution response message to the internal service module 111 and configure the outbound firewall policy at the same time. The specific execution order is not limited in this application.

[0153] S711: T-box11's internal service module 11 generates IP addresses based on user requests.

[0154] S712: The internal service module 111 of T-box11 sends the IP address to the outbound firewall module 113 of T-box11.

[0155] In some embodiments, when the internal service module 111 of T-BOX11 sends the IP address corresponding to the URL address to the outbound firewall module 113 of T-box11, it needs to go through the routing module 112.

[0156] S713: The outbound firewall module 113 of T-box11 determines the validity of the received IP address. If the IP address is valid, step S714 is executed. The following text provides a detailed description of the dynamic firewall regulation configuration and IP address validity determination by the outbound firewall module 113, which will not be repeated here.

[0157] S714: The outbound firewall module 113 of the T-box11 sends the legitimate IP address to the server 30-1.

[0158] From the above Figures 5 to 7As described, the DNS relay module 115 of T-box 11 can parse domain name resolution request messages to obtain URL addresses. Based on a pre-saved URL whitelist, it verifies the validity of the obtained URL addresses. If the obtained URL addresses are valid, it records the peer information of the IVI 12 and / or internal service module 111 that sent the domain name resolution request message in a mapping table. This peer information can be used to verify the validity of domain name resolution response messages obtained from server 30-1. If the domain name resolution response message is determined to be valid, the DNS relay module 115 of T-box 11 parses the domain name resolution response message to obtain IP addresses. The DNS relay module 115 of T-box 11 can record the obtained IP addresses and their corresponding information in a list of entries. The IP addresses recorded in this list are the IP address whitelist, which can be used to set outbound firewall configuration rules, allowing the outbound firewall module 113 to only allow IP addresses in the IP address whitelist to access server 30-1.

[0159] It is understandable that, through the above Figures 5 to 7 As can be seen from the description, the method of this application can control APN access during the DNS message resolution process, and can also update the IP address whitelist in real time based on the IP address obtained from the domain name resolution response message. Based on the real-time updated IP address whitelist, illegal IP addresses can be filtered, thereby reducing the attack path of illegal access data. This not only improves the granularity of illegal access data detection, but also improves the real-time performance of legitimacy verification and defense effectiveness.

[0160] Figure 8 A schematic diagram of an application of a DNS relay module 115 based on existing technology is shown, such as... Figure 8 As shown, the DNS relay module 115 in the prior art includes a listening unit 1151 and a forwarding unit 1155.

[0161] Figure 8 The DNS relay module 115 shown is mainly used to forward DNS resolution request messages and DNS resolution response messages between the DNS client and the DNS server. Specifically, the DNS client sends a DNS resolution request message to the DNS relay module 115, meaning the destination address of the DNS resolution request message is the IP address of the DNS relay module 115. After receiving the DNS resolution request message, the DNS relay module 115 forwards the message to the DNS server. The DNS server performs DNS resolution on the request message, obtains a DNS resolution response message, and sends the response message to the DNS relay module 115. After receiving the response message from the DNS server, the DNS relay module 115 forwards the message to the DNS client.

[0162] Figure 8 The DNS relay module 115 can receive domain name resolution request messages and / or domain name resolution response messages, and forward them to the corresponding domain name resolution server and / or DNS client. Although Figure 8 The application of the DNS relay module 115 simplifies network management. When the address of the domain name resolution server changes, only the configuration on the DNS relay module 115 needs to be changed, without changing the configuration of each DNS client within the local area network. However, existing DNS relays cannot solve the aforementioned network access control problems; for example, they cannot control unauthorized access to server 30-1.

[0163] This application proposes a DNS relay module 115, which improves upon the existing DNS relay module 115 by integrating the improved module into T-Box 11. This module verifies the legitimacy of domain name resolution request messages and / or domain name resolution response messages, parses legitimate domain name resolution response messages to obtain IP addresses, and stores these IP addresses in an IP address whitelist. This whitelist is then used to configure the firewall policy of the outbound firewall module 113. When an IP address to be accessed passes through the outbound firewall module 113, its legitimacy is verified, allowing only legitimate IP addresses to access server 30-1. This prevents unauthorized IP addresses from accessing the server, improves the granularity of network access control detection, and further enhances the real-time performance of legitimacy verification and the effectiveness of defense.

[0164] Figure 9 A schematic diagram of the composition structure of the DNS relay module 115 of this application is shown, as follows: Figure 9 As shown, the DNS relay module 115 includes a listening unit 1151, a resolution verification unit 1152, a firewall rule management unit 1153, a mapping table unit 1154, and a forwarding unit 1155.

[0165] The following describes in detail the components of the DNS relay module 115.

[0166] Listening unit 1151: Used to receive domain name resolution request messages and record the peer information in the mapping table of mapping table unit 1154.

[0167] Parsing and verification unit 1152: Used to parse domain name resolution response messages or domain name resolution request messages.

[0168] Firewall rule management unit 1153: Used to set firewall configuration rules for outbound firewall module 113.

[0169] Mapping table unit 1154: Used to store the peer information of the mapping table.

[0170] Forwarding unit 1155: Used to receive domain name resolution response messages from domain name resolution server 30-3, or to send domain name resolution response messages to IVI12 or internal service module 111.

[0171] The following describes in detail the process by which the DNS relay module 115 of T-box 11 in step S604 or S704 above processes and forwards domain name resolution request messages, taking into account the composition structure of the DNS relay module 115.

[0172] Based on the above Figure 9 The DNS relay module 115 shown below has a structural composition. The following describes in detail the execution process of domain name resolution request message processing and forwarding through the interaction process between the listening unit 1151, the mapping table unit 1154, and the resolution verification unit 1152.

[0173] Figure 10 According to an embodiment of this application, an interactive flowchart of the various units of a DNS relay module 115 is shown when the DNS relay module 115 performs domain name resolution request message processing and forwarding.

[0174] like Figure 10 As shown, after the domain name resolution request message from IVI12 and / or internal service module 111 is redirected to DNS relay module 115, the listening unit 1151, mapping table unit 1154, resolution verification unit 1152, and forwarding unit 1155 of DNS relay module 115 cooperate to complete the domain name resolution request message processing and forwarding process. The specific process includes:

[0175] S1001: Listening unit 1151 received a domain name resolution request message.

[0176] In some embodiments, the domain name resolution request message can be from an IVI12 DNS request or from an internal service module 111. For example, in Figure 5 In network access control (a), the domain name resolution request message is a DNS request from IVI12. Figure 5 (b) In the network access control, the domain name resolution request message is a DNS request from the internal service module 111.

[0177] S1002: The monitoring unit 1151 records the peer information in the mapping table of the mapping table unit 1154.

[0178] In some embodiments, the peer information includes, but is not limited to, IP address and port number information. For example, when the listening unit 1151 receives a domain name resolution request message from IVI12, the listening unit 1151 records the peer information of IVI12 in the mapping table of the mapping table unit 1154, so as to serve as the basis for the resolution verification unit 1152 of the DNS relay module 115 to verify the legality of the domain name resolution response message.

[0179] S1003: The listening unit 1151 sends the domain name resolution request message to the resolution verification unit 1152.

[0180] S1004: The parsing and verification unit 1152 parses the domain name resolution request message and obtains the URL address.

[0181] S1005: Parsing and verification unit 1152 determines whether the URL address is valid based on the URL whitelist.

[0182] For example, the parsing and verification unit 1152 can match the URL whitelist located in the memory with the URL address obtained in step S1005 according to the URL whitelist provided in advance by the industry (e.g., car manufacturers) to determine whether the URL address is in the URL whitelist. If the URL address exists in the URL address whitelist, it means that the URL address is valid. If the URL address is valid, step S1007 is executed. If the URL address does not exist in the URL address whitelist, it means that the URL address is invalid. If the URL address is invalid, step S1006 is executed.

[0183] S1006: The resolution verification unit 1152 discards the domain name resolution request message.

[0184] S1007: The resolution verification unit 1152 sends the domain name resolution request message to the domain name resolution server 30-3.

[0185] Depend on Figure 10 As described in the DNS relay module 115, each unit performs domain name resolution request message processing and forwarding interaction. The DNS relay module 115's resolution verification unit 1152 can parse the domain name resolution request message to obtain a URL address, match the obtained URL address with a URL whitelist, and discard the domain name resolution request message if the URL whitelist does not contain the obtained URL address. It can be understood that by verifying the legitimacy of the URL address obtained from resolving the domain name resolution request message, attack paths for unauthorized data access are reduced, and the overall system's attack defense timeline is advanced. This avoids the situation where URL address filtering only applies to unencrypted HTTP services and also avoids the situation where defense actions only occur at the application layer, resulting in a late defense timing.

[0186] Furthermore, the listening unit 1151 of the DNS relay module 115 can record the peer information in the mapping table of the mapping table unit 1154 for use by the resolution verification unit 1152 of the DNS relay module 115 below to verify the validity of the domain name resolution response message.

[0187] The following describes in detail the process by which the DNS relay module 115 of T-box 11 in step S608 or S708 above processes and forwards domain name resolution response messages, taking into account the composition structure of the DNS relay module 115.

[0188] Based on the above Figure 9 The DNS relay module 115 shown below has a structural composition. The following describes in detail the execution process of responding to and forwarding domain name resolution request messages through the interaction process between the forwarding unit 1155, the mapping table unit 1154, the resolution verification unit 1152, and the firewall rule management unit 1153.

[0189] Figure 11 According to an embodiment of this application, an interaction flowchart of the various units of the DNS relay module 115 when performing domain name resolution response message processing and forwarding is shown; as follows: Figure 11 As shown, the specific process includes:

[0190] In some embodiments, when the modified DNS relay receives a domain name resolution response message from the domain name resolution server 30-3, the forwarding unit 1155, the mapping table unit 1154, the resolution verification unit 1152, and the firewall rule management unit 1153 cooperate to complete the domain name resolution response message processing and forwarding process. The specific process includes:

[0191] S1101: Forwarding unit 1155 receives a domain name resolution response message sent from domain name resolution server 30-3.

[0192] S1102: Forwarding unit 1155 sends the domain name resolution response message to resolution verification unit 1152.

[0193] S1103: The parsing and verification unit 1152 obtains the peer information recorded in the mapping table from the mapping table unit 1154.

[0194] Depend on Figure 10As can be seen from step S1002, after receiving the domain name resolution request message from IVI12, the listening unit 1151 records the peer information of IVI12 in the mapping table of the mapping table unit 1154. After the forwarding unit 1155 sends the domain name resolution response message to the resolution verification unit 1152, the resolution verification unit 1152 retrieves the peer information recorded in the mapping table from the mapping table unit 1154 and determines whether the domain name resolution response message is valid based on the peer information.

[0195] S1104: The resolution verification unit 1152 determines whether the domain name resolution response message is valid based on the peer information.

[0196] For example, if the peer information in the mapping table of mapping table unit 1154 is the peer information of IVI12 that sent the domain name resolution request message, then the resolution verification unit 1152 compares the peer information in the domain name resolution response message with the peer information of IVI12 that sent the domain name resolution request message obtained from the mapping table of mapping table unit 1154. If the comparison is successful, it means that the domain name resolution response message is valid, and step S1106 is executed; if the comparison is unsuccessful, it means that the domain name resolution response message is invalid, and step S1105 is executed.

[0197] S1105: Resolution verification unit 1152 discards domain name resolution response messages.

[0198] S1106: The parsing and verification unit 1152 parses the domain name resolution response message and obtains the IP address.

[0199] S1107: The parsing and verification unit 1152 sends the IP address and the information corresponding to the IP address to the firewall rule management unit 1153.

[0200] In some embodiments, the parsing and verification unit 1152 sends the IP address and the information corresponding to the IP address to the firewall rule management unit 1153; wherein, the information corresponding to the IP address includes, but is not limited to, the URL address corresponding to the IP address, the time to live (TTL) of the IP address, and APN information.

[0201] In some embodiments, the TTL of an IP address can be used to limit the duration of an IP address's presence in network access. APN information can be used to determine the APN for IP address access, thereby determining which server (e.g., a private cloud server, a public cloud server) the IP address can access.

[0202] S1108: Firewall rule management unit 1153 sets the firewall configuration rules for outbound firewall module 113. The following section describes in detail the setting of firewall configuration rules for outbound firewall module 113, which will not be repeated here.

[0203] S1109: The resolution verification unit 1152 sends a domain name resolution response message to the forwarding unit 1155.

[0204] S1110: Forwarding unit 1155 determines the domain name resolution response message to be sent to IVI12 or internal service module 111 based on the peer information of the mapping table in the mapping table of mapping table unit 1154.

[0205] Understandably, the forwarding unit 1155 can determine whether to send the domain name resolution response message to IVI12 or the internal service module 111 based on the peer information in the mapping table. For example, if the peer information in the mapping table of the mapping table unit 1154 is the peer information of IVI12, then the forwarding unit 1155 will send the domain name resolution response message to IVI12. If the peer information in the mapping table of the mapping table unit 1154 is the peer information of the internal service module 111, then the forwarding unit 1155 will send the domain name resolution response message to IVI12.

[0206] In some embodiments, the firewall configuration rules of the outbound firewall module 113 can be configured by the firewall rule management unit 1153 of the DNS relay module 115. The firewall rule management unit 1153 includes an information form branch, a monitoring branch, a policy configuration branch, and a connection state detection branch.

[0207] Figure 12 The present invention provides a schematic diagram of the composition structure of a firewall rule management unit 1153 according to some embodiments of the present application.

[0208] like Figure 12 As shown, the firewall rule management unit 1153 includes an information form branch 1160, a monitoring branch 1161, a policy configuration branch 1163, and a connection state detection branch 1162.

[0209] Information form branch 1160: Used to manage the list of entries; for example, adding or deleting entries. Each entry in the list records an IP address and the information corresponding to that IP address, including but not limited to the URL address corresponding to the IP address, the Time To Live (TTL) of the IP address, and APN information.

[0210] Monitoring branch 1161: Used to periodically check the validity period of each item in the list of items of information form branch 1160, and to determine whether the list of items of information form branch 1160 contains expired items.

[0211] Policy configuration branch 1163: Used to manage firewall rule configurations; for example, to apply firewall rule configurations or to delete firewall rule configurations corresponding to expired entries.

[0212] Connection status detection branch 1162: Used to determine whether the IP address of an expired entry is still in use.

[0213] The following describes in detail the process of setting firewall configuration rules for outbound firewall module 113 by firewall rule management unit 1153, taking into account its composition structure.

[0214] Figure 13 According to an embodiment of this application, the flowchart shown illustrates the firewall configuration rules set by the firewall rule management unit 1153 for the outbound firewall module 113, specifically including:

[0215] S1301: The firewall rule management unit 1153 receives the IP address and the corresponding information sent by the resolution and verification unit 1152, and adds a new entry to the entry list in the information form branch 1160 of the firewall rule management unit 1153.

[0216] In some embodiments, each entry in the list of entries is used to record an IP address and the information corresponding to that IP address. The information corresponding to the IP address includes, but is not limited to, the URL address corresponding to the IP address, the Time To Live (TTL) of the IP address, and APN information.

[0217] S1302: The firewall rule management unit 1153 notifies the policy configuration unit 1163 of the IP address and the information corresponding to the IP address. The policy configuration unit 1163 then sends the effective firewall configuration rules to the outbound firewall module 113 and records the index information of the effective configuration in the table entry list.

[0218] It is understandable that firewall configuration rules can be determined based on the IP addresses recorded in the entry list and the information corresponding to those IP addresses. That is, the entry list contains IP addresses used to verify permission to access server 30-1, i.e., an IP address whitelist. When internal service module 111 and / or IVI12 access server 30-1 using an IP address, outbound firewall module 113 can determine whether the IP address of the server 30-1 to be accessed is valid based on the IP address whitelist. Only if the IP address is valid will access to server 30-1 be permitted.

[0219] To ensure the real-time validity of the IP address whitelist and prevent the interruption of existing communication services and disruption of normal business processes due to IP address expiration, the firewall rule management unit 1153 monitors the IP address whitelist and connection status in real time. When an IP address in the IP address whitelist expires, it will be deleted without affecting the user experience, thus preventing subsequent access to the server by expired IP addresses.

[0220] The following section describes in detail the process of real-time monitoring of IP addresses performed by the firewall rule management unit 1153, taking into account its structural composition.

[0221] Figure 14 According to an embodiment of this application, the flowchart shown illustrates the firewall configuration rules set by the firewall rule management unit 1153 for the outbound firewall module 113, specifically including:

[0222] S1401: Monitor branch 1161 periodically to check the validity period of each entry in the entry list of information form branch 1160.

[0223] In some embodiments, each entry in the list of entries records the IP address obtained by resolving the domain name resolution response message, as well as the information corresponding to the IP address. The information corresponding to the IP address includes, but is not limited to, the URL address corresponding to the IP address, the Time To Live (TTL) of the IP address, and APN information.

[0224] S1402: Monitoring branch 1161 determines whether the list of entries in information form branch 1160 contains expired entries.

[0225] For example, monitoring branch 1161 can periodically check the TTL of the IP address in each entry of the information form branch 1160's entry list, and determine whether the entry list contains expired entries based on the TTL of the IP address in each entry. If the entry list does not contain expired entries, return to step S1401; if the entry list contains expired entries, execute step S1403.

[0226] S1403: Connection status detection branch 1162 determines whether the IP address of an expired entry is currently in use.

[0227] For example, if the IP address of an expired entry is in use, i.e., the internal service module 111 and / or IVI12 is using the IP address of an expired entry to access server 30-1, return to step S1401; if the IP address of an expired entry is not in use, i.e., the internal service module 111 and / or IVI12 is not using the IP address of an expired entry to access server 30-1, execute step S1404.

[0228] S1404: Policy configuration branch 1163 deletes the firewall configuration rules corresponding to expired entries.

[0229] S1405: Information form branch 1160 deletes expired entries from the list of entries.

[0230] Depend on Figure 14 As shown in the real-time monitoring process of the IP address, the monitoring branch 1161 periodically checks whether the TTL corresponding to the IP address of each entry in the table list of the information form branch 1160 has expired. If the table list contains expired entries, the connection status detection branch 1162 determines whether the IP address of the expired entry is in use. If the IP address is in use, it returns to step S1401 and continues to execute steps S1401 to S1403, that is, it monitors whether the IP addresses in the IP address whitelist have expired and determines whether the expired IP addresses are in use. If the expired IP address is not in use, it deletes the expired IP address from the IP address whitelist. This ensures that the user experience is not affected, and the expired IP address is deleted, thus ensuring the performance of network access control and preventing subsequent illegal IP addresses from accessing the server 30-1.

[0231] In some embodiments, such as Figure 1 In the scenario shown, server 30 may include, but is not limited to, a telematics service provider (TSP) server, a domain name resolution server, etc. The domain name resolution server has domain name resolution capabilities, enabling it to parse domain name resolution request messages and obtain IP addresses.

[0232] For example, a TSP server can be used to provide multimedia information, navigation, and other in-vehicle services. For instance, both server 30-1 and server 30-2 are TSP servers. Server 30-1 can be a private cloud server, for example, used to provide data information related to vehicle control for the service platform. This data information may include: vehicle driving data, vehicle trajectory data, road condition data around the vehicle, driving behavior analysis data, etc. Server 30-2 can be a public cloud server; for example, used to provide multimedia audio-visual entertainment data for the service platform.

[0233] For example, such as Figure 1 In the scenario shown, the in-vehicle device 10 may include an in-vehicle communication terminal (Telematics BOX, T-box) 11 and an in-vehicle entertainment device (IVI) 12. The T-box 11 can communicate with the IVI 12 via wired or wireless means; for example, wired communication can be achieved through a USB interface or an in-vehicle Ethernet interface; wireless communication can be achieved through wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), near field communication (NFC), or other wireless communication networks.

[0234] For example, such as Figure 1 In the scenario shown, IVI12 can communicate with electronic device 20, and also with server 30-1 or server 30-2 via T-Box11. This allows IVI12 to provide services to in-vehicle device 10, including data monitoring, real-time navigation, web browsing, and direct access to in-vehicle applications (apps). It can also enable electronic device 20 to control the vehicle or transmit data to in-vehicle device 10. For example, IVI12 can remotely monitor and operate the vehicle via an app on electronic device 20-1, and IVI12 can share data with electronic device 20-2. Electronic device 20 includes, but is not limited to, mobile phones, tablets, smart car keys, and USB flash drives. Electronic device 20 and IVI12 can connect via wired or wireless communication; specific connection methods are similar to those between IVI12 and T-box11 and will not be elaborated here.

[0235] For example, such as Figure 1In the scenario shown, T-Box 11 is primarily used to communicate with server 30 and / or IVI 12, enabling interaction between the in-vehicle device 10 and internet information. For example, T-Box 11 can access server 30-1 via APN1, allowing vehicle 40 to communicate with server 30-1 in the vehicle control domain. This provides T-Box 11 and / or IVI 12 with services including driving data collection, driving trajectory recording, vehicle fault monitoring, remote vehicle query and control (locking / unlocking, air conditioning control, window control, engine torque limiting, engine start / stop), and driving behavior analysis. T-Box 11 can also access server 30-2 via APN2, enabling vehicle 40 to communicate with server 30-1 in the information service domain, providing IVI 12 with support for online entertainment applications such as online music, weather, news, real-time traffic, inbox, and stock information.

[0236] Figure 15 A schematic block diagram of the hardware structure of an in-vehicle communication terminal 11 is shown.

[0237] like Figure 15 As shown, the vehicle-mounted communication terminal 11 includes: a GPS (Global Positioning System) antenna, a 3G / 4G / 5G antenna, a C-V2X (Cellula Vehicle-to-Everything) antenna, a WLAN (Wireless Local Area Network) antenna, and multiple radio frequency units, a system-on-chip (SOC) 150, a security hardware module 156, a multimedia card 155, a SIM (Subscriber Identification Module) card 154, a power management unit 151, a microcontroller unit 152, a pin connector 153, etc.

[0238] In some embodiments, Figure 15The multiple antennas and radio frequency units within the device can be used for communication with the external network of the vehicle, or for internal communication connections within the in-vehicle device 10. For example, after establishing a communication connection between the in-vehicle entertainment device 12 and the in-vehicle communication terminal 11, it can send domain name resolution request messages to the in-vehicle communication terminal 11, receive domain name resolution response messages sent by the in-vehicle communication terminal 11, and send IP addresses, etc. It can be understood that establishing a communication connection between the in-vehicle communication terminal 11 and the in-vehicle entertainment device 12 enables the in-vehicle entertainment device 12 to access the server 30 through the in-vehicle communication terminal 11. For example, after the vehicle-mounted communication terminal 11 establishes a communication connection with server 30-1 or server 30-2, it can access server 30-1 or server 30-2 to provide the vehicle-mounted device 10 with entertainment and communication services, including data monitoring, real-time navigation, web browsing, and direct use of vehicle applications (apps). The vehicle-mounted communication terminal 11 can provide the vehicle-mounted device 10 with vehicle control services, including driving data collection, driving trajectory recording, vehicle fault monitoring, remote vehicle query and control (locking and unlocking, air conditioning control, window control, engine torque limiting, engine start and stop), and driving behavior analysis.

[0239] In some embodiments, the SOC150 integrates a processor, memory, system-on-a-chip control logic module, multiple interface control modules, and multiple interconnect buses to provide control, computing, or storage functions for the vehicle communication terminal 11.

[0240] In some embodiments, the processor integrated in the SOC150 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. In this embodiment, the processor integrated in the SOC150 can be used to authenticate or filter unauthorized access data. For example, the processor integrated in the SOC150 can obtain IP addresses in real time through domain name resolution, create an IP address whitelist based on the obtained IP addresses, and update the IP address whitelist in real time. The vehicle communication terminal determines the allowed IP addresses to access the server based on the IP address whitelist, thereby achieving real-time network access control, preventing unauthorized IP addresses from accessing the server, and improving the granularity of unauthorized data detection.

[0241] The integrated memory of the SOC150 can be used not only to store computer executable program code, including instructions, but also to store URL whitelists, mapping tables recording peer information, IP address whitelists, etc. The integrated memory of the SOC150 may include a program storage area and a data storage area. In some embodiments, the integrated memory of the SOC150 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor integrated in the SOC150 executes various functional applications and data processing of the vehicle communication terminal 11 by running instructions stored in the integrated memory of the SOC150 and / or instructions stored in memory located in the processor.

[0242] In some embodiments, the microcontroller unit 152, as a processor implementation, can also provide control or computing functions for the vehicle communication terminal 11.

[0243] In some embodiments, when the mobile communication terminal 11 accesses the cellular communication network, it can use the SIM (Subscriber Identification Module) card in the vehicle communication terminal 11 to identify its identity.

[0244] In some embodiments, the security hardware module 156 can be used to provide security protection for the vehicle-mounted device 10 to access the external network.

[0245] In some embodiments, the multimedia card can be used to provide storage functionality for the vehicle communication terminal 11.

[0246] In some embodiments, the power management unit provides power management for the vehicle communication terminal 11.

[0247] In some embodiments, the vehicle communication terminal 11 also interacts with other components within the vehicle via multiple buses (e.g., CAN bus, Ethernet bus) and interfaces (e.g., microphone interface, speaker interface). For example, the vehicle communication terminal 11 can acquire access data via multiple buses. This access data could be received access data from the IVI 12, detected by the access server 30, which generates data based on a user request. Alternatively, the access data could be access data detected by the vehicle communication terminal 11 from the access server 30, generated based on a user request.

[0248] It is understood that the hardware structure involved in the vehicle communication terminal 11 for communicating with the vehicle entertainment device 12 or the server 30 is not limited to... Figure 15 The communication interfaces, modules, or connectors shown may be used by the vehicle-mounted communication terminal 11 to communicate with the vehicle-mounted entertainment device 12 or the server 30 in various forms, including but not limited to 2G (second-generation mobile communication technology), 3G (third-generation mobile communication technology), 4G (fourth-generation mobile communication technology), 5G (fifth-generation mobile communication technology), Wi-Fi (Wireless Fidelity), WiMAX (Worldwide Interoperability for Microwave Access), Bluetooth, ZigBee, optical communication, satellite communication, or infrared communication.

[0249] Understandable, Figure 15 The illustrated structure does not constitute a specific limitation on the vehicle communication terminal 11. In other embodiments of this application, the vehicle communication terminal 11 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0250] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0251] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

[0252] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0253] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0254] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0255] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0256] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0257] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

Claims

1. A network access control method, characterized in that, include: The vehicle-mounted communication terminal obtains a domain name resolution request message, wherein the domain name resolution request message includes a first URL address; When the first URL address meets the first preset condition, the vehicle communication terminal sends the domain name resolution request message to the domain name resolution server, wherein the first preset condition includes: the first URL address meets the legal conditions of the URL list preset by the vehicle manufacturer; The vehicle-mounted communication terminal receives a domain name resolution response message generated by the domain name resolution server after the domain name resolution server performs domain name resolution on the first URL address, wherein the domain name resolution response message includes the first IP address; When the domain name resolution response message meets the second preset condition, the vehicle-mounted communication terminal adds the first IP address to the IP address whitelist.

2. The method according to claim 1, characterized in that, The URL list includes at least one of the following: a URL address whitelist, a URL address blacklist, and a set of illegal character rules.

3. The method according to claim 1, characterized in that, Also includes: When the first URL address meets the first preset condition, the vehicle-mounted communication terminal records the peer information of the generated domain name resolution request message in the mapping table; The peer information includes at least one of the following: the IP address of the device that generated the domain name resolution request message, and the port number of the device that generated the domain name resolution request message.

4. The method according to claim 3, characterized in that, When the domain name resolution response message meets the second preset condition, the vehicle-mounted communication terminal adds the first IP address to the IP address whitelist, including: When the domain name resolution response message contains peer information from the mapping table, the vehicle-mounted communication terminal adds the first IP address to the IP address whitelist.

5. The method according to claim 1, characterized in that, Also includes: If the vehicle-mounted communication terminal detects that the IP address whitelist contains an expired second IP address, and that the expired second IP address is not currently accessing an external server, The vehicle-mounted communication terminal deletes the expired second IP address from the IP address whitelist.

6. The method according to claim 5, characterized in that, The vehicle-mounted communication terminal detects whether the IP address whitelist contains an expired second IP address based on the lifespan of the first IP address in the IP address whitelist.

7. The method according to claim 1, characterized in that, Also includes: The vehicle-mounted communication terminal obtains a third IP address generated in response to the user's access request. If the vehicle-mounted communication terminal contains a third IP address in its IP address whitelist, the third IP address is allowed to access the external server.

8. The method according to claim 1, characterized in that, The vehicle-mounted communication terminal is a vehicle networking terminal box.

9. A readable medium, characterized in that, The readable medium stores instructions that, when executed on the vehicle-mounted communication terminal, cause the vehicle-mounted communication terminal to perform the network access control method according to any one of claims 1 to 8.

10. A vehicle-mounted communication terminal, characterized in that, include: One or more processors; One or more memories; the one or more memories store one or more programs that, when executed by the one or more processors, cause the vehicle-mounted communication terminal to perform the network access control method according to any one of claims 1 to 8.

Images