Monitoring device, system, method, and program

Abstract

This network device (1) comprises: an eBPF user unit (13A) that registers a policy file (33B) transmitted via a secure channel as a policy (16C) in the network device (1) itself; and a device monitoring control unit (15A) that monitors communication between applications operating on a virtualization infrastructure (12) outside the virtualization infrastructure (12) and detects communication between the applications not conforming to the policy (16C) as communication between unauthorized applications. The device monitoring control unit (15A) detects communication between the applications that do not conform to the policy (16C) by referencing a process map (16B) that maps information on processes of the applications and a socket list (16D) that indicates socket communication between the applications.

Description

Monitoring Device, Monitoring System, Monitoring Method, and Monitoring Program

[0001] The present invention relates to a monitoring device, a monitoring system, a monitoring method, and a monitoring program.

[0002] As a security function, a technology has been proposed that monitors communication between applications performed on a NW (Network) and detects communication that violates the NW policy (communication policy). The application operates in an execution environment called a Pod on a virtualization infrastructure, and communication between the Pods is the target of monitoring. Non-Patent Document 1 describes Kubernetes used as a virtualization infrastructure. In Kubernetes, generally, iptables / netfilter of Linux (registered trademark) is used to perform communication between Pods using the NW policy. The maintainer sets the rules for communication between Pods using the NW policy that describes the following information. ・Receiving port / transmitting port ・IP address block ・Port number ・Permission / rejection, etc. And the kube-proxy of Kubernetes monitors and controls communication between Pods based on the set NW policy.

[0003] However, in communication between Pods where a large number of processes dynamically and temporarily change IP addresses and port numbers, a large number of rule changes are required, and as the number of Pods increases, the processing load also increases (O(n)). Also, if the kube-proxy of Kubernetes is operated in the ipvs mode, it is O(1), but since it is processed in the user space, the processing load becomes a bottleneck under conditions with high performance requirements.

[0004] Therefore, Non-Patent Document 2 describes Cilium, which is a plugin that replaces the processing of iptables with processing using eBPF (extended Berkeley Packet Filter). Since processing is directly executed in the kernel space in eBPF, the processing load is reduced compared to Kubernetes. Also, in policy creation using eBPF, there is an eBPF policy separate from the NW policy. In Cilium, the eBPF policy and the NW policy are associated.

[0005] The Kubernetes Authors, "Kubernetes", [online], [searched December 11, 2024], Internet <URL: https: / / kubernetes.io> The Cilium Authors, "Cilium", [online], [searched December 11, 2024], Internet <URL: https: / / cilium.io>

[0006] Conventional technologies, such as those described in Non-Patent Documents 1 and 2, monitor inter-Pod communication on the premise that the configured NW policy is correct and has not been tampered with. Therefore, in situations where the NW policy is tampered with, as described below, there is a risk that inter-Pod communication will not be properly monitored. - The operating environment of the device running the Pod (such as a virtualization infrastructure) may be subjected to security attacks, such as malware infection. Note that the device running the Pod sends and receives data with external parties, including the telecommunications carrier, so it is at high risk of being attacked on the NW policy. - The management device, which sets the NW policy for the device running the Pod from the outside, may be subjected to security attacks, such as malware infection. In this case, the management device is used as a stepping stone (intermediate point) to carry out an attack on the device running the Pod.

[0007] Furthermore, Cilium, described in Non-Patent Document 2, manages network policies in user space using information such as the Kubernetes manifest described in Non-Patent Document 1. Therefore, the robustness against malware infection or attack is equivalent between Non-Patent Documents 1 and 2. However, if the network policy is tampered with due to malware infection, the following risks occur: - Information leakage risk occurs because communication occurs between Pods that are not permitted to communicate under the correct network policy. - A DoS (Denial of Service Attack) risk occurs because communication is disabled between Pods that are permitted to communicate under the correct network policy.

[0008] Furthermore, as an example of an attack on the virtualization infrastructure, an attack method has been reported in which arbitrary code is executed on the host OS from a container within a Pod. While attacks can be avoided by properly configuring container permissions, there is a risk of similar attacks due to unknown vulnerabilities. Note that container escape attacks include, for example, attacks that access the host OS from a privileged container and execute arbitrary code on the host OS, making it possible to verify the root file system within the container. Examples include: • An attack that executes arbitrary code registered as a release_agent program on the host OS. • An attack that executes arbitrary code described in the uevent_helper file on the host OS. • An attack that uses the core_pattern file to generate a coredump and escape to the host side.

[0009] Therefore, the main objective of the present invention is to provide a mechanism that can monitor the state of the operating environment even if the setting information of the operating environment is illegally tampered with.

[0010] To solve the aforementioned problems, the monitoring device of the present invention comprises the following means. The present invention is characterized by having a policy registration unit that registers a policy file transmitted via a secure channel as a communication policy within its own device, and a device monitoring control unit that monitors communication between applications operating in an operating environment from outside the operating environment and detects communication between applications that does not conform to the communication policy as unauthorized communication between applications.

[0011] According to the present invention, a mechanism is provided that allows monitoring of the operating environment status even if the operating environment settings information is illegally altered.

[0012] This is a configuration diagram of a network device according to this embodiment. This is a detailed configuration diagram of the device monitoring control unit and eBPF storage unit according to this embodiment. This is a configuration diagram of a communication monitoring system according to this embodiment. This is an explanatory diagram of a communication monitoring system having multiple network devices according to this embodiment. This is an explanatory diagram showing an example of policy file creation in a communication monitoring system having multiple network devices as shown in Figure 4 according to this embodiment. This is a sequence diagram showing the process of establishing a secure channel with the controller when the network device is started up according to this embodiment. This is a sequence diagram showing the generation process of each file in the controller's DB and the network device's eBPF storage unit according to this embodiment. This is a sequence diagram showing the generation process of each file in the controller's DB and the network device's eBPF storage unit, following Figure 7 according to this embodiment. This is an explanatory diagram showing the details of the process of linking the process ID, process name, and application name according to this embodiment. This is a sequence diagram showing the creation of a socket list according to this embodiment. This is an explanatory diagram of the eBPF storage unit according to this embodiment. This is a flowchart showing the server-side processing of inter-application TCP (Transmission Control Protocol) communication using sockets in the network device according to this embodiment. This is a flowchart showing the client-side processing of inter-application TCP communication using sockets in the network device according to this embodiment. This is an explanatory diagram showing the process map creation process in the file sharing policy according to this embodiment. This is an explanatory diagram of the file access monitoring process using the process map shown in Figure 14 according to this embodiment. This is an explanatory diagram of the process map creation process in the resource sharing policy according to this embodiment. This is an explanatory diagram of the resource utilization monitoring process using the process map shown in Figure 16 according to this embodiment. This is a flowchart of the server-side processing of inter-application UDP (User Datagram Protocol) communication using sockets in a network device according to this embodiment. This is a flowchart of the client-side processing of inter-application UDP communication using sockets in a network device according to this embodiment. This is a hardware configuration diagram of each device in the communication monitoring system according to this embodiment.

[0013] One embodiment of the present invention will be described in detail below with reference to the drawings.

[0014] Figure 1 is a configuration diagram of network device 1. Network device (monitoring device) 1 has a host OS 14 that runs on physical resources 19, and a virtualization infrastructure 12 and user space 13 formed on the host OS 14. Within the user space 13, the eBPF user unit (policy registration unit) 13A is executed. The NIF unit 18 sends and receives data with the control device 2 and controller 3 in Figure 3, other applications within the same network device 1, and other network devices 1. The virtualization infrastructure 12 is an execution environment for running various applications (server application 11A and client application 11B), and each application is assigned a virtual IP address that is identified in the network space on the virtualization infrastructure 12. Client application 11B requests services from server application 11A. Now, let's assume that the virtualization infrastructure 12 has become infected with malware 12X due to an application container escape attack or the like. In this embodiment, a virtualization infrastructure 12 is used as an example of the application's operating environment, but a single OS running on a physical resource 19 may be used instead of the virtualization infrastructure 12 as the application's operating environment.

[0015] Each server application 11A operates a logically independent network service, as illustrated below. In other words, the virtualization infrastructure 12 is the foundation for operating and controlling multiple network functions provided by each server application 11A on the network device 1. These include: • HTTPS (Hypertext Transfer Protocol Secure) • DNS (Domain Name System) • 5GC (5G Core network) • Wireless base station functions such as CU (Central Unit) and DU (Distributed Unit)

[0016] The virtualization infrastructure 12 has an application management unit 12A that manages the applications running. The application management unit 12A configures applications and the host OS 14 based on network configuration information, and changes the operational status of applications (start / stop, etc.) according to instructions (config files) from the API unit 21A (Figure 3) of the control device 2. The kernel 15 in the host OS 14 contains system calls 12D such as fork and exec that are executed in response to config information from the application management unit 12A, a device monitoring control unit 15A that monitors the system calls 12D and collects pids, etc., and an eBPF storage unit 16 that stores data used by the device monitoring control unit 15A.

[0017] The eBPF storage unit 16 stores a configuration file (Config file) 16A, a process map 16B, a policy 16C, and a socket list 16D as information that links the process ID, process name, and application name in the host OS 14. The contents of the eBPF storage unit 16 are shared between the device monitoring control unit 15A and the eBPF user unit 13A. The eBPF user unit 13A stores the configuration file 33A and policy file 33B received from the eBPF monitoring unit 31 (Figure 3) of the controller 3 as configuration file 16A and policy 16C in the eBPF storage unit 16. In other words, the eBPF user unit 13A registers the policy file 33B transmitted via a secure channel as policy 16C within its own device. Furthermore, the configuration file 33A and policy file 33B, which are taken into the network device 1 via the eBPF user section 13A, are outside the scope of the malware 12X's influence (outside the virtualization infrastructure 12), thus preventing tampering with policy 16C. The configuration file 16A contains configuration information related to the network device 1, including process names. Policy 16C contains configuration information related to inter-application communication (NW policy = communication policy), which is information that links the pid of each application in the host OS 14 with the application name.

[0018] The process map 16B is a database that links the process ID of an application on the host OS 14, the process name of the system call 12D, and the application name on the virtualization infrastructure 12. In other words, the process map 16B is information that links the process ID of the server application 11A outside the virtualization infrastructure 12, the process name of the system call 12D, and the name of the application outside the virtualization infrastructure 12. The device monitoring control unit 15A generates the process map 16B by associating the process information of the server application 11A observed inside and outside the virtualization infrastructure 12 with each other.

[0019] The socket list 16D is a database that associates pairs of arguments of system calls 12D hooked by the device monitoring control unit 15A of the network device 1 where the socket server application 11A is running, with process IDs. System calls 12D are, for example, socket,bind,listen. Arguments of system calls 12D are, for example, the type of communication protocol, the server's IP address, and the port number. Examples of communication protocol types include TCP, UDP, and ICMP (Internet Control Message Protocol). Thus, the socket list 16D is information that associates the type of communication protocol in socket communication with the process ID of the server application 11A, the IP address of the server application 11A, and the port number of the server application 11A (see Figure 11 for details). The device monitoring control unit 15A generates the socket list 16D showing socket communication between server applications 11A obtained from system calls 12D observed outside the virtualization infrastructure 12.

[0020] The device monitoring control unit 15A operates by being integrated into the kernel 15 of the host OS 14. The device monitoring control unit 15A collects system calls 12D and monitors the establishment of inter-process communication sessions in order to monitor system calls 12D that may lead to unauthorized inter-application communication. The device monitoring control unit 15A then performs control such as preventing unauthorized session establishment. For this reason, the device monitoring control unit 15A monitors system calls 12D related to inter-application communication using sockets using eBPF. eBPF is a kernel 15 function that hooks system calls 12D in the kernel 15 and collects information about the system calls 12D and controls them (such as rewriting or discarding arguments).

[0021] In other words, the device monitoring control unit 15A monitors communication between server applications 11A running on the virtualization infrastructure 12 from outside the virtualization infrastructure 12 and detects communication between server applications 11A that does not conform to policy 16C as unauthorized communication between applications. To this end, the device monitoring control unit 15A refers to the process map 16B and the socket list 16D to detect communication between server applications 11A that does not conform to policy 16C. As a result, the device monitoring control unit 15A collects information such as the type of system call, the process ID of the application that issued the system call, the IP addresses and port numbers of the server and client sides of the socket. The device monitoring control unit 15A then creates the process map 16B and the socket list 16D from the collected information and stores them in the eBPF storage unit 16. The device monitoring control unit 15A then uses the process map 16B, policy 16C, and socket list 16D to control whether to allow or deny communication between applications.

[0022] Figure 2 is a detailed configuration diagram of the device monitoring control unit 15A and the eBPF storage unit 16. The kernel 15 includes the device monitoring control unit 15A (eBPF VM 15B, Perf 15C) and the eBPF storage unit 16 (eBPF maps 16X, eBPF ring buffer 16Y), similar to existing eBPF functions. The device monitoring control unit 15A performs monitoring processing of inter-application communication using the socket list 16D according to the following procedure: (Procedure 1) A system call 12D (connect, bind, listen) is made from the server application 11A to the kernel 15. (Procedure 2) The eBPF function of the device monitoring control unit 15A collects (pid, ip, port) from the system call 12D in (Procedure 1). pid is the server's process ID, ip is the server's IP address, and port is the server's port number (value in the host OS). (Step 3) The eBPF function of the device monitoring control unit 15A registers the collected (pid, ip, port) to the server-side port in the socket list 16D, and checks if there is an application name corresponding to the pid that matches the ip and port.

[0023] The eBPF monitoring unit 31 of the controller 3 (Figure 3) monitors the processes of the eBPF user unit 13A in order to monitor the health of the eBPF function of the device monitoring control unit 15A. As preparation for this, the eBPF user unit 13A and the eBPF monitoring unit 31 support mutual authentication and encrypted communication via a secure channel (mTLS). The eBPF user unit 13A then monitors the processes of each of the following elements based on the respective commands: - eBPF VM 15B (load command) within the device monitoring control unit 15A - Perf 15C etc. (attach command) within the device monitoring control unit 15A - eBPF maps 16X (read / write command) for configuring the eBPF storage unit 16 - eBPF ring buffer 16Y (read / write command) for configuring the eBPF storage unit 16

[0024] Figure 3 is a diagram of the communication monitoring system 100. The communication monitoring system (monitoring system) 100 includes a control device 2 and a controller 3, in addition to the network device 1 described in Figure 1 (a part of the internal structure is shown in Figure 3). The control device 2 is an OS 22 on a physical resource 23 on which a virtualization infrastructure 21 is constructed. The virtualization infrastructure 21 includes an API unit 21A that transmits configuration information 21Z to the application management unit 12A, and an NIF unit 21B that relays communication with other devices such as the network device 1 and the controller 3.

[0025] Maintenance user 2X is a legitimate user of control device 2. Through operations via API unit 21A from maintenance user 2X, they control each application of network device 1 (start / stop, etc.) and set legitimate policies 16C on the virtualization infrastructure 12 of each network device 1. On the other hand, let's assume a situation where the virtualization infrastructure 21 is infected with malware 21X by attacker 2Y, an unauthorized user. Malware 21X can also infect the virtualization infrastructure 12 as malware 12X via the virtualization infrastructure 21.

[0026] Controller 3 externally executes the coordinated process management between the host OS 14 in the network device 1 and the process management in the virtualization infrastructure 12, as well as the control process of the host OS 14 corresponding to the policy 16C of the virtualization infrastructure 12. To this end, Controller 3 establishes a secure channel by mutual authentication with Network Device 1 and transmits the policy file 33B it created to Network Device 1 via this secure channel. Controller 3 includes an eBPF monitoring unit 31, a file generation unit 32, a DB 33, an FE (Front End) 34, and an NIF unit 39. The DB 33 stores the configuration file 33A and the policy file 33B. The NIF unit 39 relays communication with other devices such as Network Device 1 and Control Device 2.

[0027] Maintenance user 3X is a legitimate user of controller 3, and has a division of authority relationship with maintenance user 2X of control device 2. FE 34 receives network configuration information entered by maintenance user 3X and notifies the file generation unit 32 of this information. The file generation unit 32 uses the network configuration information obtained from FE 34 to create files in DB 33 (configuration file 33A and policy file 33B). Configuration file 33A is a Config file for setting network configuration information in the application management unit 12A of network device 1. Policy file 33B is a file that describes the NW policy for each application of each network device 1, and is registered as policy 16C of network device 1. In other words, policy file 33B and policy 16C have the same content.

[0028] A secure channel (encrypted session) such as mTLS (mutual Transport Layer Security) is established between the eBPF monitoring unit 31 and the eBPF user unit 13A. The eBPF monitoring unit 31 transmits the policy file 33B to the eBPF user unit 13A of each network device 1 via the secure channel from the NIF unit 39. This reduces the risk of tampering with the policy 16C even if the virtualization infrastructure 12 or applications are infected with or attacked by malware 12X. The NIF unit 39 also transmits the configuration file 33A to the API unit 21A of the control device 2.

[0029] Furthermore, the eBPF monitoring unit 31 notifies the maintenance person 3X of the following information indicating the health of the network device 1: • Information indicating when a secure channel is established and when it is disconnected during the process of establishing a secure channel with the eBPF user unit 13A of the network device 1 when the network device 1 starts up. • Information detected by the eBPF monitoring unit 31 by monitoring the health of the eBPF user unit 13A of the network device 1 via the secure channel. This detected information includes, for example, information that the startup status of a process (starting / stopped) has changed. Note that if the user space 13 is infected with malware 12X and the eBPF user unit 13A is attacked, the eBPF user unit 13A will stop, allowing the eBPF monitoring unit 31 to detect an abnormality in the eBPF user unit 13A.

[0030] In this way, the controller 3 monitors the startup status of the eBPF user section 13A via a secure channel and determines the health of the network device 1 based on changes in its startup status. This makes it possible to protect the eBPF function in the user space 13 of the network device 1 even if the virtualization infrastructure 12 is infected with malware 12X or is under attack.

[0031] Then, the eBPF monitoring unit 31 of the controller 3 monitors the health of each network device 1 and detects a network device 1 that is suspected of being infected with malware or under attack. In that case, the file generation unit 32 creates a new NW policy (policy file 33B) that rejects communication to all applications running on the detected network device 1 and distributes the NW policy to each network device 1.

[0032] As described above, the communication monitoring system 100 enables the newly introduced controller 3 to monitor and control inter-application communication via the kernel 15 by coordinating with the device monitoring and control unit 15A of the network device 1. Therefore, the reliability of monitoring and control can be improved compared to monitoring and controlling inter-application communication in the virtualization infrastructure 12 or user space 13. Consequently, even if data tampering occurs in the virtualization infrastructure 12 or user space 13 due to the influence of malware 12X on the network device 1, and the risk of unauthorized inter-application communication or communication blocking arises, the decrease in the reliability of monitoring and control can be mitigated. Furthermore, if the newly introduced controller 3 is implemented as a plug-in to the control device 2, unauthorized access and other issues can be monitored in the kernel of the OS 22.

[0033] Furthermore, the controller 3 generates a policy file 33B to monitor inter-application communication. This allows the controller 3 to centrally manage the monitoring of inter-application communication across multiple network devices 1. Therefore, the controller 3 distributes the policy file 33B to each network device 1, and the kernel 15 generates a process map 16B and a socket list 16D to monitor the socket system call 12D. This enables each network device 1 to monitor and control inter-application communication on the host OS with minimal latency.

[0034] Figure 4 is an explanatory diagram of a communication monitoring system 100 having multiple network devices 1. Figure 3 describes a communication monitoring system 100 that manages one network device 1. Figure 4 describes a communication monitoring system 100 that manages two (multiple) network devices 1. The API unit 21A of the control device 2 distributes configuration information 21Z based on the configuration file 33A of the controller 3 to the application management unit 12A of each network device 1. The application management unit 12A stores the distributed configuration information 21Z as a configuration file 16A in the eBPF storage unit 16 and issues a system call 12D.

[0035] The controller 3 distributes a normal policy 33X based on the policy file 33B to the kernel 15 of each network device 1. Each network device 1 stores (registers) the distributed normal policy 33X as policy 16C in the eBPF storage unit 16.

[0036] Figure 5 is an explanatory diagram showing an example of creating a policy file 33B in a communication monitoring system 100 having multiple network devices 1 as shown in Figure 4. The policy file 33B is a combination of a received policy 201 and a transmitted policy 202, where the contents of the received policy 201 are reflected in the transmitted policy 202.

[0037] Regarding the receiving policy 201 (the receiving policy listed in the DB server's NW policy file), the communication monitoring system 100 assumes that the following applications are running (the IP addresses assigned are shown in brackets): ・HTTP server [100.100.10.10] ・AP server [100.100.10.20] ・DB server [100.100.10.30] ・DNS server [100.100.20.10] ・HTTP server [100.100.30.10] ・Authentication server [100.100.20.30] Of these, the DB server, which is server application 11A, has the receiving policy set to "Reject reception from anything other than the AP server".

[0038] Regarding the transmission policy 202 (a network policy that provides an overview of the entire network), the reception policy of the DB server, which is the server application 11A, "Application name: PostgreSQL, Reception: Reject all IPs except 100.100.10.20", is reflected in the transmission policy of each client application 11B, such as the DNS server, "Sending: Reject IP: 100.100.10.30". In this way, the file generation unit 32 of the controller 3 generates a policy file 33B (reception policy 201, transmission policy 202) as shown in Figure 5, based on instructions from the maintenance person 3X via the FE 34. In other words, based on the reception and transmission permission / denial of each policy file 33B between the opposing applications, the file generation unit 32 sets the NW policy of the sending client application 11B to deny if the receiving server application 11A denies it.

[0039] Figure 6 is a sequence diagram showing the process of establishing a secure channel with the controller 3 when the network device 1 is started up. The maintenance worker 3X starts up the network device 1 either on-site where it is installed or online (S101). The network device 1 requests the eBPF monitoring unit 31 to establish an mTLS session (S102). The eBPF user unit 13A and the eBPF monitoring unit 31 establish an mTLS session by performing an mTLS session establishment process (including mutual authentication) (S103) (S104).

[0040] In other words, in steps S102 to S104, the eBPF user unit 13A of the network device 1 establishes an mTLS session for secure communication with the eBPF monitoring unit 31 of the controller 3. When establishing the mTLS session, the eBPF user unit 13A uses a nonce to deter malware or attackers from communicating with the eBPF monitoring unit 31 illegally (replay attack). Furthermore, the network device 1 stores its private key in its secure area and performs mutual authentication (mTLS) to deter malware or attackers from communicating with the eBPF monitoring unit 31 illegally.

[0041] When the eBPF user unit 13A completes its startup process, it responds to the eBPF monitoring unit 31 with the startup status as "Starting" (S105), and the eBPF monitoring unit 31 notifies the maintenance worker 3X of the startup status (S106). The eBPF monitoring unit 31 periodically sends confirmation messages to the eBPF user unit 13A regarding the startup status (starting / stopped) of the process of the eBPF user unit 13A (S107). If the network device 1 is running, the eBPF user unit 13A responds to the eBPF monitoring unit 31 with the startup status as "Starting" (S108), and the eBPF monitoring unit 31 notifies the maintenance worker 3X that it is starting up (S109).

[0042] In addition, when the eBPF user part 13A terminates abnormally (S110) or when the network device 1 is not started, the eBPF monitoring part 31 detects a timeout (S112) because there is no response from the eBPF user part 13A to the process startup state confirmation message (S111), and notifies the maintainer 3X that it is "stopped" (S113). As described above, the eBPF user part 13A establishes a secure channel (mTLS) with the eBPF monitoring part 31 of the controller 3 when the network device 1 is started.

[0043] FIG. 7 is a sequence diagram showing the generation process of each file in the DB 33 of the controller 3 and the eBPF storage part 16 of the network device 1. Hereinafter, in FIGS. 7 and 8, the process of generating the setting file 33A and the policy file 33B in the DB 33 and the process map 16B in the eBPF storage part 16 will be described.

[0044] The maintainer 3X designs and inputs the configuration information of the network to be managed at the FE 34 of the controller 3, and inputs the network configuration information to the file generation part 32 of the controller 3 via the FE 34 (S201). This network configuration information includes the following information. - Application name for executing a specific function of the network (https, DNS, 5GC, CU, DU, RU, etc.) in each network device 1 - Command name for starting the application - Information for controlling the possibility of communication between applications - Allocation amount of resources such as CPU and memory possessed by the network device 1 - Application-specific parameter information when executing the application

[0045] The file generation unit 32 generates a configuration file (Config file) 33A and a policy file 33B for an application that processes a specific function constituting the network from the input network configuration information, and stores them in the DB 33 (S202). The configuration file 33A describes the name of the application (app name), the process name, etc. The process name is obtained, for example, from the command name for starting the application. The policy file 33B describes the app name, information about other apps with which the app can communicate, etc. (see Policy 16C in FIG. 9 for details).

[0046] The file generation unit 32 transmits the configuration file 33A to the API unit 21A of the control device 2 and requests the start of the application corresponding to the configuration file 33A (S203). The API unit 21A selects a network device 1 on which the application can be started based on the content of the configuration file 33A and the resource usage amounts of the CPU, memory, etc. of each network device 1 (S204). The API unit 21A notifies the file generation unit 32 of the information of the network device 1 selected in S204 (S205).

[0047] The API unit 21A generates request data for starting the application and setting the network configuration information for the network device 1 (S206). The API unit 21A requests the start of the application based on the generated request data in S206 to the app management unit 12A of the network device 1 selected in S204 based on the content of the configuration file 33A (S207).

[0048] The app management unit 12A of the network device 1 starts the application. At this time, the app management unit 12A of the network device 1 issues system calls of fork() and exec() to the kernel of the host OS (S208). The device monitoring control unit 15A registers fork() and exec() in advance as system calls to be collected (hooked) and detects these system calls (S209).

[0049] The device monitoring control unit 15A obtains the process ID and process name of the launched application. For example, the process ID is obtained using the get_syscall_fnname() function provided by eBPF. The process name is obtained from the command name used to launch the application, which is specified in the argument of exec(). The device monitoring control unit 15A stores the obtained process ID and process name in the eBPF storage unit 16 (S210).

[0050] Figure 8 is a sequence diagram showing the file generation process in the DB 33 of the controller 3 and the eBPF storage unit 16 of the network device 1, following Figure 7. The file generation unit 32 generates the NW policy for the application to be launched on the network device 1, which was notified in S205 from the policy file 33B (S211), and notifies the eBPF monitoring unit 31 (S212). The eBPF monitoring unit 31 sends the NW policy from the configuration file 33A and S211 to the network device 1 (S213).

[0051] The eBPF user unit 13A stores the configuration file 33A and the NW policy from S211 received in S213 as configuration file 16A and policy 16C in the eBPF storage unit 16 (S214). The device monitoring control unit 15A retrieves the configuration file 16A that matches the process name stored in the eBPF storage unit 16 in S210 (S215).

[0052] The device monitoring control unit 15A identifies the application name from the acquired configuration file 16A (S216). At this time, the NW policy associated with the configuration file 16A can also be identified from the application name. The device monitoring control unit 15A associates the process ID, process name, and application name, registers them in the process map 16B, and stores the process map 16B in the eBPF storage unit 16 (S217).

[0053] Figure 9 is an explanatory diagram showing the details of the process (S217) that links the process ID, process name, and application name. Policy 16C, as the NW policy of the virtualization infrastructure 12, contains information such as the IP address (IP addr), port number (Port No.), protocol number, and application name of the other application to be allowed or denied for each packet received or sent by each application. Policy file 33B is in the same format as policy 16C. Configuration file 16A, as the Config file of the virtualization infrastructure 12, contains information equivalent to the manifest of Kubernetes. The process name in configuration file 16A is the command name used when starting the application, and is equivalent to the command, arg, etc. of a Container Object in Kubernetes.

[0054] The host OS 14 maintains information about the processes it runs, specifically (pid*, process name), that is, the correspondence between process IDs and process names. The device monitoring control unit 15A, in cooperation with the controller 3, creates a process map 16B that links the process ID of the host OS 14, the process name in the configuration file 16A, and the application name in the policy 16C (S217). In other words, the device monitoring control unit 15A associates the NW policy and the eBPF policy as a process map 16B from outside the operating environment (virtualization infrastructure 12) to be monitored. Thus, the process map 16B maps the rules for inter-application communication defined in the NW policy of the virtualization infrastructure 12 to the rules for inter-process communication of the host OS 14. Furthermore, the device monitoring control unit 15A monitors and controls the health of inter-application communication at the host OS 14 level by determining whether to allow or deny inter-application communication based on the process map 16B.

[0055] Figure 10 is a sequence diagram showing the creation of the socket list 16D. First, the processing in TCP connection communication will be explained in S221 to S223. After startup, the server application 11A of the network device 1 issues the system calls socket(), bind(), and listen() to the kernel 15 of the host OS 14 in order to communicate with other applications using sockets (S221). The device monitoring control unit 15A has registered socket(), bind(), and listen() as system calls to be acquired (collected) (hooked) in advance, and when it detects these system calls (S222), it acquires the type of communication protocol (TCP), the process ID and IP address of the application that issued the system call, and the server-side port number.

[0056] As an example, the device monitoring control unit 15A obtains the process ID using the get_syscall_fnname() function provided by eBPF. The IP address and server-side port number are obtained from the arguments of bind(). Then, the device monitoring control unit 15A registers the following sets of obtained information in the socket list 16D as a list of servers listening via socket, and stores them in the eBPF storage unit 16 (S223). • Type of communication protocol obtained from the arguments of socket() • Application process ID and IP address • Server-side port number

[0057] Next, the processing in connectionless communication using UDP will be explained in S224 to S226. After startup, the server application 11A of the network device 1 issues the socket() and bind() system calls to the host OS kernel in order to communicate with other applications using sockets (S224). The device monitoring control unit 15A has registered socket() and bind() as system calls to be acquired (collected) (hooked) in advance, and when it detects these system calls (S225), it acquires the type of communication protocol (UDP), the process ID and IP address of the application that issued the system call, and the server-side port number.

[0058] As an example, the device monitoring control unit 15A obtains the process ID using the get_syscall_fnname() function provided by eBPF. The IP address and server-side port number are obtained from the arguments of bind(). Then, the device monitoring control unit 15A registers the obtained application process ID, IP address, and server-side port number pairs as a list of the server-side entries that created the socket in the socket list 16D and stores them in the eBPF storage unit 16 (S226). The type of communication protocol is obtained from the arguments of socket().

[0059] Figure 11 is an explanatory diagram of the eBPF storage unit 16. As shown by arrow 311, the device monitoring control unit 15A detects system calls 12D (socket, bind, listen, etc.) that the server-side eBPF of the socket hooks, and creates a list of pairs of arguments and process IDs (type, pid, ip, port) as a socket list 16D (processing as explained in Figure 10). type is the type of communication protocol such as TCP, UDP, or ICMP, pid is the process ID of the server application 11A, ip is the IP address, and port is the port number.

[0060] Figure 12 is a flowchart showing the server-side processing of inter-application TCP communication using a socket on network device 1. When a packet arrives from client application 11B to a socket where server application 11A is listening(), device monitoring control unit 15A detects the accept() system call issued by server application 11A (S301). Device monitoring control unit 15A has registered accept() as a system call to be collected (hooked) in advance, and collects the client's IP address and port number from the arguments when this system call is detected (S302).

[0061] Furthermore, the device monitoring control unit 15A collects the process ID of the server application 11A that issued the system call (S303). For example, the client's IP address is obtained from the arguments of accept(). The process ID of the server application 11A that issued the system call is collected using the get_syscall_fnname() function provided by eBPF.

[0062] Then, the device monitoring control unit 15A searches the socket list 16D for the process ID of the server application 11A that issued accept(), confirms that this process was listening(), and obtains the server-side port number (S304). The device monitoring control unit 15A searches the process map 16B for the application name associated with the server-side process ID and identifies it (S305).

[0063] The device monitoring control unit 15A retrieves a policy 16C with the application name identified by searching the process map 16B from the eBPF storage unit 16 (S306). The device monitoring control unit 15A checks the NW policy for "reception" in the policy 16C retrieved from the eBPF storage unit 16 (S307). The device monitoring control unit 15A compares the client-side IP address collected in S302 and the server-side port number collected in S304 with the policy 16C confirmed in S307. If it is included in the "allowed" section of policy 16C (Yes in S308), it continues processing the accept() system call to receive the packet (S309). If it is not included in the "allowed" section of policy 16C (No in S308), it terminates the accept() system call and discards the received packet (S310).

[0064] The process shown in Figure 12 described above will be supplemented with reference to Figure 11. As shown by arrow 311 in Figure 11, the device monitoring control unit 15A detects the accept() system call 12D issued by the server application 11A (S301) and collects the process ID (pid) of the server application 11A from the socket list 16D (S303). As shown by arrow 312, the device monitoring control unit 15A searches for and identifies the application name paired with the server-side process ID (pid*) from the process map 16B (S305). As shown by arrow 313, the device monitoring control unit 15A checks the NW policy for "reception" of policy 16C obtained from the eBPF storage unit 16 (S307). In this way, the device monitoring control unit 15A controls whether to allow or deny inter-application communication according to the NW policy (policy 16C) by associating the process ID of the system call 12D with the process ID of the process map 16B and the process ID of the socket list 16D.

[0065] Figure 13 is a flowchart showing the client-side processing of application-to-application TCP communication using sockets on network device 1. The device monitoring control unit 15A detects the connect() system call issued by the client application 11B of network device 1 to send a packet to the server application 11A (S321). The device monitoring control unit 15A has registered connect() as a system call to be collected (hooked) in advance, and collects the server's IP address and port number from the arguments when this system call is detected (S322).

[0066] Furthermore, the device monitoring control unit 15A collects the process ID of the client application 11B that issued the system call (S323). For example, the server's IP address and port number are obtained from the arguments of connect(). The process ID of the client application 11B that issued the system call is collected using the get_syscall_fnname() function provided by eBPF.

[0067] The device monitoring control unit 15A searches the process map 16B for and identifies the application name associated with the process ID of the client application 11B (S324). The device monitoring control unit 15A retrieves the policy 16C with the application name identified by searching the process map 16B from the eBPF storage unit 16 (S325).

[0068] The device monitoring control unit 15A checks the NW policy for "transmission" in policy 16C obtained from the eBPF storage unit 16 (S326). The device monitoring control unit 15A compares the server-side IP address and port number collected in S322 with policy 16C confirmed in S326 (S327). If the comparison is found to be included in "permission" in policy 16C (Yes in S327), the device monitoring control unit 15A continues processing the connect() system call and performs packet transmission processing (S328). If the connection is not included in "permission" in policy 16C (No in S327), the device monitoring control unit 15A terminates the connect() system call and discards the packet to be transmitted (S329).

[0069] The process shown in Figure 13 described above will be supplemented with reference to Figure 11. As shown by arrow 321 in Figure 11, the device monitoring control unit 15A detects the connect() system call 12D issued by the client application 11B (S321), and searches for and identifies the application name associated with the process ID of the client application 11B from the process map 16B (S324). As shown by arrow 322, the device monitoring control unit 15A checks the NW policy for "transmission" of policy 16C obtained from the eBPF storage unit 16 (S326). In this way, the device monitoring control unit 15A controls whether to allow or deny inter-application communication according to the NW policy (policy 16C) by associating the process ID of the system call 12D with the process ID of the process map 16B.

[0070] The above describes the monitoring and control of inter-application communication based on the NW policy as an example of policy 16C of network device 1. On the other hand, policy 16C can also be applied to the following policies in addition to the NW policy for monitoring and control: ・Monitoring and control of application file access based on the file sharing policy (explained in Figures 14 and 15). File access refers to access to shared files / directories provided by the host OS 14 of network device 1. Monitoring of file access refers to, for example, monitoring the number of simultaneous accesses to shared files. ・Monitoring of application-specific usage (resource usage) of the physical resources 19 of network device 1 based on the resource sharing policy (explained in Figures 16 and 17). The usage of physical resources 19 refers to, for example, the amount of CPU and memory used, and can be monitored using the eBPF observation function.

[0071] Figure 14 is an explanatory diagram of the process for creating the process map 16B in the file sharing policy. In Figure 9, the content of policy 16C was information indicating permission or denial for each packet sent and received (NW policy), but in Figure 14, it is replaced with information indicating the accessible (mounted) path of the shared file (file sharing policy). The device monitoring and control unit 15A executes the process for creating the process map 16B in the file sharing policy in Figure 14, similar to the process for creating the process map 16B in the NW policy described in Figure 9.

[0072] Figure 15 is an explanatory diagram of the file access monitoring process using the process map 16B in Figure 14. The inter-application communication monitoring process described by arrows 321 and 322 in Figure 11 is replaced by the following process. The device monitoring control unit 15A detects file access system calls 12D such as open(pathname, fd). pathname is the path to the file to be accessed, and fd is the file descriptor. Based on the process map 16B, the device monitoring control unit 15A obtains the process ID of the file accessing process from the eBPF observation function and searches for the application name associated with the process ID. The device monitoring control unit 15A checks the accessible files from the policy 16C (file sharing policy) in Figure 14.

[0073] Figure 16 is an explanatory diagram of the process for creating the process map 16B in the resource sharing policy. In Figure 9, the content of policy 16C was information indicating permission or denial for each packet sent and received (NW policy), but in Figure 16, it is replaced with a resource request file from the virtualization infrastructure 12 to the physical resource 19 (resource sharing policy). The device monitoring and control unit 15A executes the process for creating the process map 16B in the resource sharing policy in Figure 16, similar to the process for creating the process map 16B in the NW policy described in Figure 9.

[0074] Figure 17 is an explanatory diagram of the resource utilization monitoring process using the process map 16B in Figure 16. The inter-application communication monitoring process described by arrows 321 and 322 in Figure 11 is replaced by the following process. The device monitoring control unit 15A detects, for example, CPU=100m (milliseconds) as the resource utilization status for each application identified by (pid*, process name). Note that if one CPU core is occupied, the CPU usage will be 1000m. Based on the process map 16B, the device monitoring control unit 15A obtains the process ID for resource utilization from the eBPF observation function and searches for the application name associated with the process ID. The device monitoring control unit 15A checks the amount of available resources from the policy 16C (resource sharing policy) in Figure 16.

[0075] Figure 18 is a flowchart showing the server-side processing of inter-application UDP communication using a socket on network device 1. The device monitoring control unit 15A detects the recvfrom() system call issued by server application 11A when a packet arrives from client application 11B in a socket created by server application 11A of network device 1 (S401). The device monitoring control unit 15A has registered recvfrom() in advance as a system call to be collected (hooked), and collects the client's IP address and port number from the arguments when this system call is detected (S402).

[0076] Furthermore, the device monitoring control unit 15A collects the process ID of the server application 11A that issued the system call (S403). For example, the client's IP address is obtained from the arguments of recvfrom(). The process ID of the server application 11A that issued the system call is collected using the get_syscall_fnname() function provided by eBPF.

[0077] The device monitoring control unit 15A searches the socket list 16D for the process ID of the server application 11A that issued recvfrom() and confirms that this process has created a socket. As a result of this confirmation, the device monitoring control unit 15A obtains the server-side port number (S404). The device monitoring control unit 15A searches the process map 16B for the application name associated with the server-side process ID and identifies it (S405).

[0078] The device monitoring control unit 15A searches the process map 16B and obtains a policy 16C with the identified application name from the eBPF storage unit 16 (S406). The device monitoring control unit 15A checks the NW policy for "reception" of the policy 16C obtained from the eBPF storage unit 16 (S407).

[0079] The device monitoring control unit 15A compares the client-side IP address collected in S402 and the server-side port number collected in S404 with the policy 16C confirmed in S407 (S408). If the policy 16C includes "permission" (Yes in S408), the device monitoring control unit 15A continues processing the recvfrom() system call to receive the packet (S409). If the policy 16C does not include "permission" (No in S408), the device monitoring control unit 15A terminates the recvfrom() system call and discards the received packet (S410).

[0080] Figure 19 is a flowchart showing the client-side processing of inter-application UDP communication using sockets on network device 1. The device monitoring control unit 15A detects the sendto() system call issued by the client application 11B of network device 1 to send a packet to the server application 11A (S421). The device monitoring control unit 15A has registered sendto() in advance as a system call to be collected (hooked), and when this system call is detected, it collects the server's IP address and port number from the arguments (S422).

[0081] Furthermore, the device monitoring control unit 15A collects the process ID of the client application 11B that issued the system call (S423). For example, the server's IP address and port number are obtained from the arguments of sendto(). The process ID of the client application 11B that issued the system call is collected using the get_syscall_fnname() function provided by eBPF.

[0082] The device monitoring control unit 15A searches the process map 16B for and identifies the application name associated with the process ID of the client application 11B (S424). The device monitoring control unit 15A retrieves the policy 16C with the application name identified by searching the process map 16B from the eBPF storage unit 16 (S425).

[0083] The device monitoring control unit 15A checks the NW policy for "transmission" in policy 16C obtained from the eBPF storage unit 16 (S426). The device monitoring control unit 15A compares the server-side IP address and port number collected in S422 with policy 16C confirmed in S426 (S427). If it is included in "permission" in policy 16C (Yes in S427), the device monitoring control unit 15A continues processing the sendto() system call and performs packet transmission processing (S428). If it is not included in "permission" in policy 16C (No in S427), the device monitoring control unit 15A terminates processing the sendto() system call and discards the packet to be transmitted (S429).

[0084] Figure 20 is a hardware configuration diagram of each device in the communication monitoring system 100. Each device in the communication monitoring system 100 (network device 1, control device 2, controller 3) is configured as a computer 900 having a CPU 901, RAM 902, ROM 903, HDD 904, communication I / F 905, input / output I / F 906, and media I / F 907, respectively. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data to the recording medium 917. Furthermore, the CPU 901 controls each processing unit by executing a program (monitoring program) loaded into the RAM 902. This program (application, also called an app) can be distributed via a communication line or recorded on a recording medium 917 such as a USB memory stick and distributed.

[0085] [Effects] The network device 1 of the present invention is characterized by having an eBPF user unit 13A that registers a policy file 33B transmitted via a secure channel as policy 16C within its own device, and a device monitoring control unit 15A that monitors communication between applications operating on the virtualization infrastructure 12 from outside the virtualization infrastructure 12 and detects communication between applications that does not conform to policy 16C as unauthorized communication between applications.

[0086] As a result, the network device 1 can provide a mechanism to monitor the state of the operating environment, such as detecting unauthorized communication between applications even if policy 16C (configuration information) is illegally altered due to malware infection of the virtualization infrastructure 12 (operating environment).

[0087] The network device 1 of the present invention is characterized in that the device monitoring control unit 15A detects communication between applications that does not conform to policy 16C by referring to a process map 16B that associates information on application processes observed inside and outside the virtualization infrastructure 12 with each other, and a socket list 16D that shows socket communication between applications obtained from system calls 12D observed outside the virtualization infrastructure 12.

[0088] As a result, the network device 1 collects information from system calls 12D invoked by the application, rather than from the application itself. This minimizes the impact on the application's processing performance while enabling high-speed (real-time) monitoring of communication between applications. Furthermore, it eliminates the need to modify the application's software for information collection.

[0089] The network device 1 of the present invention is characterized in that the device monitoring control unit 15A generates information as a process map 16B, which links the process ID of an application outside the virtualization infrastructure 12, the process name of a system call 12D, and the name of the application outside the virtualization infrastructure 12.

[0090] As a result, network device 1 can correctly associate the same application both inside and outside the virtualization infrastructure 12, even if the identification information for the same application differs in notation between the process ID and the process name.

[0091] The network device 1 of the present invention is characterized in that the device monitoring control unit 15A generates information as a socket list 16D, which associates the type of communication protocol in socket communication with the application's process ID, the application's IP address, and the application's port number.

[0092] This allows the network device 1 to correctly associate the application information described in policy 16C with the application information obtained from system call 12D as the same application.

[0093] The present invention relates to a communication monitoring system 100 comprising a network device 1 and a controller 3, characterized in that the controller 3 establishes a secure channel by mutual authentication with the network device 1, and transmits a policy file 33B that it has created to the network device 1 via that secure channel.

[0094] As a result, even if the virtualization infrastructure 12 of the network device 1 is infected with malware 12X, the communication monitoring system 100 can ensure that the legitimate policy 16C from policy file 33B is used instead of the policy modified by malware 12X.

[0095] The communication monitoring system 100 of the present invention is characterized in that the controller 3 monitors the startup status of the eBPF user unit 13A via a secure channel and determines the health of the network device 1 based on changes in that startup status.

[0096] This allows the communication monitoring system 100 to efficiently detect abnormalities in the eBPF user unit 13A. Even if the user space 13 of the network device 1 is infected with malware, the eBPF user unit 13A will shut down if it is under attack.

[0097] 1 Network device (monitoring device) 2 Control device 3 Controller 11A Server application (application) 11B Client application (application) 12 Virtualization infrastructure (operating environment) 12D System call 13A eBPF user section (policy registration section) 15A Device monitoring control unit 16B Process map 16C Policy 16D Socket list 33B Policy file 100 Communication monitoring system (monitoring system)

Claims

1. A monitoring device characterized by having a policy registration unit that registers a policy file transmitted via a secure channel as a communication policy within its own device, and a device monitoring control unit that monitors communication between applications operating in an operating environment from outside the operating environment and detects communication between applications that does not conform to the communication policy as unauthorized communication between applications.

2. The monitoring device according to claim 1, wherein the device monitoring control unit detects communication between applications that does not conform to the communication policy by referring to a process map that associates information on the application processes observed inside and outside the operating environment with each other, and a socket list that shows socket communication between applications obtained from system calls observed outside the operating environment.

3. The monitoring device according to claim 2, characterized in that the device monitoring control unit generates information as the process map, which associates the process ID of the application outside the operating environment with the process name of the system call and the name of the application outside the operating environment.

4. The monitoring device according to claim 2, characterized in that the device monitoring control unit generates information as the socket list, which associates the type of communication protocol in socket communication with the process ID of the application, the IP address of the application, and the port number of the application.

5. A monitoring system comprising a monitoring device according to any one of claims 1 to 4 and a controller, wherein the controller establishes a secure channel by mutual authentication with the monitoring device and transmits the policy file it has created to the monitoring device via the secure channel.

6. The monitoring system according to claim 5, characterized in that the controller monitors the activation status of the policy registration unit via the secure channel and determines the health of the monitoring device based on the change in the activation status.

7. A monitoring device comprising a policy registration unit and a device monitoring control unit, wherein the policy registration unit registers policy files transmitted via a secure channel as communication policies within its own device, and the device monitoring control unit monitors communication between applications operating in an operating environment from outside the operating environment and detects communication between applications that does not conform to the communication policy as unauthorized communication between applications.

8. A monitoring program for causing a computer to function as a monitoring device according to any one of claims 1 to 4.

Images