KR20220093585A - System for analysing malicious code and operation method thereof - Google Patents

Abstract

The present disclosure relates to an operation method for a malicious code analysis system using a bare metal sandbox. The operation method includes: a step in which a client transmits a first dynamic host configuration protocol (DHCP) request to a server; a step in which the server determines first network configuration information of the client; a step in which the server transmits the first network configuration information to the client; a step in which the client transmits a pre-boot execution environment (PXE) firmware request information to the server based on the first network configuration information; a step in which the server transmits a PXE firmware image file to the client; a step in which the client performs booting based on the PXE firmware image file; a step in which the client transmits a second DHCP request to the server; a step in which the server determines second network configuration information of the client; a step in which the client makes a connection to a storage area network (SAN) target based on the second network configuration information; and a step in which the client performs booting based on an m_2 booting image file included in iSCSI LUN.

Description

Malicious code analysis system and method of operation

The present disclosure relates to a malicious code analysis system and an operating method of the system.

When building a malicious code analysis system, it is necessary to build an environment separated from the actual computer environment because the process of repeatedly infecting and recovering malicious code is required. There are largely two types of methods used to build a separate environment: a virtual machine sandbox system using software virtualization technology and a bare metal sandbox system method using a separate physical machine.

The virtual machine sandbox system creates a clean system snapshot to initialize the contaminated environment used for malicious code analysis, and the snapshot can be used for the next analysis.

The bare metal sandbox system stores a clean disk image in another server connected to the network with the client running the malicious code to initialize the contaminated environment. It can receive and restore images in a clean state from another server.

The virtual machine sandbox is faster because the amount of reading and writing to the actual physical disk for environment initialization is smaller than that of the bare metal sandbox, but many malicious codes detect the virtual environment and refuse to run it or refuse to run it in order to prevent smooth analysis. Because it behaves differently than when it is run in , a bare metal sandbox system may be required for smooth analysis.

The bare metal sandbox system stores a clean disk image in a server connected to the network to initialize the environment in which the malicious code operates. When the analysis environment is initialized, the client downloads a clean image stored in the server through PXE and writes it to the disk. This approach can cause two problems:

Usually, multiple clients can be connected to one server. At each initialization in the malicious code analysis system environment, the server transmits a disk image of about 20G to one client. If multiple clients initialize at the same time, a bottleneck may occur due to network bandwidth and the initialization time may become longer. For example, when 10 bare metal sandboxes are using 1G network bandwidth, initialization can take about 10 minutes. That is, there is a problem that the initialization time is too long compared to the bare metal sandbox system that takes 3 minutes to analyze the malicious code.

The client uses SSD rather than HDD to speed up booting. In the case of SSDs, there are restrictions on disk writes. For example, the lifetime of an SSD with a capacity of 250 Gb may be up to 150 TB of writes. As described above, if the client of the malicious code analysis system writes about 20 GB at the time of initialization, the SSD disk may need to be replaced after about 7,500 analysis. Therefore, there is a problem in that the maintenance cost of the malicious code analysis system is large.

The operating method of the malicious code analysis system using the bare metal sandbox of the present disclosure includes the steps of: a client sending a first Dynamic Host Configuration Protocol (DHCP) request to a server; and the server determining first network configuration information of the client , the server sending the first network setting information to the client, the client sending the PXE (Preboot Execution Environment) firmware request information to the server based on the first network setting information, the server sending the PXE firmware image file to the client sending, the client booting based on the PXE firmware image file, the client sending a second DHCP request to the server, the server determining the second network setting information of the client, the client setting the second network connecting to a storage area network (SAN) target based on the information, and booting the client based on an m_2 th boot image file included in the SAN target.

In the operating method of the malicious code analysis system of the present disclosure, the step of the server sending the PXE firmware image file to the client is the step of the server initializing the boot image file corresponding to the client and the initialization of the boot image file corresponding to the client is completed. , the server sending the PXE firmware image file to the client.

Transmitting the PXE firmware request information of the operating method of the malicious code analysis system of the present disclosure to the server and transmitting the PXE firmware image file to the client are performed based on a TFTP (Trivial File Transfer Protocol) protocol, and the PXE firmware request The step of sending the information to the server is characterized in that it is a READ REQUEST (RRQ) of the TFTP protocol.

In the operating method of the malicious code analysis system of the present disclosure, the step of the client sending the first DHCP request to the server includes the server sending a reboot command to the client, and when the power is turned on again, the client sends the first DHCP request to the server sending a request, the step of initializing the boot image file includes the server disconnecting the client and the SAN LUN, the server deleting the m_1 boot image file that is contaminated after malicious code analysis by the client , generating, by the server, a new m_2 th boot image file corresponding to the client based on the changed m th replication master image file, and allocating the m_2 th boot image file to the client.

The operating method of the malicious code analysis system of the present disclosure includes, when initialization of the boot image file corresponding to the client is not completed, the server does not transmit the PXE firmware image file to the client, and waits until the initialization is completed. .

The operating method of the malicious code analysis system of the present disclosure includes the steps of: the server creates a master image file after the first sub-volume is created; the initialization client boots to the master image file and then applies basic setting information to the master image file to change the master image file obtaining, the server inheriting the first sub-volume containing the changed master image file, and creating an n_1 th sub-volume that stores the m-th duplicate master image file, the server generating the n_1 th sub-volume included in the n_1 th sub-volume allocating the mth clone master image file to the client, and after the client boots to the mth clone master image file contained in the n_1 subvolume, the mth clone master image changed by applying additional setting information to the mth clone master image file acquiring the file.

The operating method of the malicious code analysis system of the present disclosure includes the steps of: the server inheriting the n_1 th sub-volume including the changed m th duplicate master image file, and creating an n_2 th sub-volume storing the m_1 th boot image file, the server allocating the m_1th boot image file included in the n_2th sub-volume to the client, and performing malware analysis after the client boots with the m_1th boot image file included in the n_2th sub-volume, and performing a malware analysis on the contaminated m_1st boot image file and transmitting the result of analysis of malicious code related to the server.

The first sub-volume and the n_1 sub-volume of the operating method of the malicious code analysis system of the present disclosure are created on a file system that supports the COW (COPY ON WRITE) function, or the COW function is implemented in software although it does not support the COW function. created on the filesystem.

The operating method of the malicious code analysis system of the present disclosure includes the steps of: the server creates a master image file after the first sub-volume is created; the initialization client boots to the master image file and then applies basic setting information to the master image file to change the master image file obtaining, the server inheriting the first sub-volume containing the changed master image file, and creating an n_1 th sub-volume that stores the m-th duplicate master image file, the server generating the n_1 th sub-volume included in the n_1 th sub-volume allocating the mth clone master image file to the client, and after the client boots to the mth clone master image file contained in the n_1 subvolume, the mth clone master image changed by applying additional setting information to the mth clone master image file acquiring the file.

The operating method of the malicious code analysis system of the present disclosure includes the steps of: the server inheriting the n_1 th sub-volume including the changed m th duplicate master image file, and creating an n_2 th sub-volume storing the m_1 th boot image file, the server allocating the m_1th boot image file included in the n_2th sub-volume to the client, and performing malware analysis after the client boots with the m_1th boot image file included in the n_2th sub-volume, and performing a malware analysis on the contaminated m_1st boot image file It further includes the step of transmitting the analysis result of the malicious code related to the server.

The operating method of the malicious code analysis system of the present disclosure includes the steps of: a client sending a first Dynamic Host Configuration Protocol (DHCP) request to a server; a server determining first network configuration information of the client; sending information to the client, the client sending Preboot Execution Environment (PXE) firmware request information to the server based on the first network setting information, the server sending a PXE firmware image file to the client, the client sending the PXE booting based on the firmware image file, the client sending a second DHCP request to the server, the server determining the second network configuration information of the client, the client based on the second network configuration information, storage (SAN) area network) connecting to the target, and booting the client based on the m_2 th boot image file included in the SAN target.

In addition, a program for implementing the operating method of the malicious code analysis system as described above may be recorded in a computer-readable recording medium.

1 is a diagram illustrating a server or a client according to an embodiment of the present disclosure.
2 is a block diagram illustrating a server or a client according to an embodiment of the present disclosure.
3 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.
4 is a block diagram illustrating a server or a client according to an embodiment of the present disclosure.
5 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.
6 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.
7 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.
8 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.

Advantages and features of the disclosed embodiments, and methods of achieving them, will become apparent with reference to the embodiments described below in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only the present embodiments allow the present disclosure to be complete, and those of ordinary skill in the art to which the present disclosure pertains. It is only provided to fully inform the person of the scope of the invention.

Terms used in this specification will be briefly described, and the disclosed embodiments will be described in detail.

Terms used in this specification have been selected as currently widely used general terms as possible while considering the functions in the present disclosure, but these may vary depending on the intention or precedent of a person skilled in the art, the emergence of new technology, and the like. In addition, in a specific case, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the description of the corresponding invention. Therefore, the terms used in the present disclosure should be defined based on the meaning of the term and the contents of the present disclosure, rather than the simple name of the term.

References in the singular herein include plural expressions unless the context clearly dictates the singular. Also, the plural expression includes the singular expression unless the context clearly dictates the plural.

In the entire specification, when a part "includes" a certain element, this means that other elements may be further included, rather than excluding other elements, unless otherwise stated.

Also, as used herein, the term “unit” refers to a software or hardware component, and “unit” performs certain roles. However, "part" is not meant to be limited to software or hardware. A “unit” may be configured to reside on an addressable storage medium and may be configured to refresh one or more processors. Thus, by way of example, “part” includes components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. The functionality provided within components and “parts” may be combined into a smaller number of components and “parts” or further divided into additional components and “parts”.

According to an embodiment of the present disclosure, “unit” may be implemented with a processor and a memory. The term "processor" should be interpreted broadly to include general purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, and the like. In some contexts, “processor” may refer to an application specific semiconductor (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), or the like. The term “processor” refers to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in combination with a DSP core, or any other such configurations. may refer to.

The term “memory” should be interpreted broadly to include any electronic component capable of storing electronic information. The term memory includes random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erase-programmable read-only memory (EPROM), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, and the like. A memory is said to be in electronic communication with the processor if the processor is capable of reading information from and/or writing information to the memory. A memory integrated in the processor is in electronic communication with the processor.

Hereinafter, with reference to the accompanying drawings, embodiments will be described in detail so that those of ordinary skill in the art to which the present disclosure pertains can easily implement them. And in order to clearly describe the present disclosure in the drawings, parts not related to the description will be omitted.

1 is a diagram illustrating a server or a client according to an embodiment of the present disclosure.

The server or client may include the control unit 100 . The controller 100 may include a processor 110 and a memory 120 . The processor 110 may execute instructions stored in the memory 120 .

The processor 110 may control an operation of a server or a client based on instructions stored in the memory 120 . A server or a client may include one processor and may include a plurality of processors. When the server or the client includes a plurality of processors, at least some of the plurality of processors may be physically spaced apart from each other. In addition, the server or the client is not limited thereto and may be implemented in various ways.

2 is a block diagram illustrating a server or a client according to an embodiment of the present disclosure. 3 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.

Hereinafter, a flowchart of the malicious code analysis system of FIG. 3 together with FIG. 2 will be described.

The malware analysis system can use the bare metal sandbox method. The malicious code analysis system may include at least one server 210 and at least one client 260 . The client 260 may include a first client 261 , a second client 262 , a third client 263 , and the like. Each of the first client 261 , the second client 262 , and the third client 263 may be a computer for analyzing at least one malicious code. In the present disclosure, the client 260 may refer to at least one of the first client 261 , the second client 262 , and the third client 263 .

According to an embodiment of the present disclosure, the server 210 may include a processor and a memory. The memory of the server 210 may include a volatile memory device and a non-volatile memory device. In addition, the volatile storage device of the server 210 may include a RAM or a RAM disk. In addition, the nonvolatile storage device of the server 210 may include an HDD or an SSD. The memory of the server 210 may store a master image file, an m-th duplicate master image file, a boot image file, and the like. The mth replication master image file may include a first replication master image file, a second replication master image file, a third replication master image file, and the like. The boot image file may include a 1_1 boot image file, a 2_1 boot image file, and a 3_1 boot image file. Here, m may be a natural number.

According to various embodiments of the present disclosure, the server 210 may include at least one server. The server 210 may include a main server and a storage server. The main server is a configuration for controlling the operation of the entire system, and can control the operation of the client. The storage server may be a server that stores data to be used by the main server or client and data generated by the main server or client. The main server may share at least a portion of hardware with the storage server. Alternatively, the main server may be implemented as hardware independent of the storage server and may be connected to each other by wire or wireless. The memory of the storage server may store a master image file, an mth clone master image file, a boot image file, and the like. The main server, storage server, and client 260 may exist on the same network. The client 260 and the storage server may be connected through iSCSI. In addition, it may not be necessary for the storage server and the main server to be connected through a network.

More specifically, when the storage server processes TFTP requests such as steps 635 and 636 according to an embodiment of the present disclosure, a network connection between the main server and the storage server may not be necessary. However, when the main server processes TFTP requests such as steps 635 and 636, the main server may need to issue sub-volume deletion and snapshot commands to the storage server. Therefore, you may need to use SSH or r-command that can give commands to the storage server from the main server, or you may need to create and use a custom protocol.

The memory of the client 260 may include a volatile memory device and a non-volatile memory device. Also, the volatile storage device of the client 260 may include a RAM or a RAM disk. The non-volatile storage of the client 260 includes read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erase-programmable read only memory (EPROM), electrical may include erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, and the like. The memory of the client 260 may have very little capacity for storing system firmware. System firmware may include BIOS or UEFI. In addition, the memory of the client 260 may store the PXE firmware so that the processor of the client 260 boots the PXE firmware. The client 260 may receive an image file of the server 210 by using the iSCSI protocol and use it as a memory. That is, the client 260 may use the network-connected image file as a memory. The image file may include various programs for analyzing an operating system (OS) and malicious code. Through the iSCSI target, memory Input/Output of the client 260 may be made through a network.

3 shows the initial setup of the malicious code analysis system. That is, the process of FIG. 3 can be performed only once when the malicious code analysis system is first built.

Referring to FIG. 3 , the server 210 may perform a step 310 of generating a master image file after creating the first sub-volume 220 . The memory of the server 210 may include at least one sub-volume. The first sub-volume 220 may be built in the memory of the server 210 . Also, a master image file may be created in the first sub-volume 220 . The master image file may be a file including a program for analyzing an operating system and malicious code. An image file refers to a disk image, and refers to a storage device such as a hard disk, a tape disk, a floppy disk, a CD/DVD/BD, and a flash disk made into a single file. The first sub-volume 220 may store the master image file.

The memory of the server 210 may have a COPY ON WRITE function. COPY ON WRITE does not create new files when duplicating original files, but refers to a technique that refers to the original files. In addition, according to the COPY ON WRITE technology, when some of the copied files are modified, a copy is created only for some of the modified files. Therefore, it is possible to reduce the overhead due to duplication of original files and duplicate files.

The server 210 may use a file system supporting a COW function in order to implement a COPY ON WRITE (COW) technology.

The server 210 may create a first sub-volume 220 or an n_1 th sub-volume 230 on a file system supporting a COPY ON WRITE (COW) function. Also, although the server 210 does not support the COW function, the first sub-volume 220 or the n_1 th sub-volume 230 may be created on a file system in which the COW function is implemented in software.

The server 210 may use a b-tree file system (Btrfs) file system. That is, the memory of the server 210 may be formatted in the Btrfs file system. Btrfs may be a file system in which COPY ON WRITE technology is implemented. Using the COPY ON WRITE technology in Btrfs to copy a sub volume or copy a file is called a snapshot. The server 210 includes a first sub-volume 220, a 2_1 sub-volume 231, a 3_1 sub-volume 232, a 4_1 sub-volume 233, a 2_2 sub-volume 241, a 3_2 sub-volume ( 242) and the 4_2 sub-volume 243 may be created on the Btrfs file system.

However, the present invention is not limited thereto, and the COPY ON WRITE technology may be implemented in software on a file system that does not support the COPY ON WRITE technology. Server 210 other than Btrfs FAT (FAT12, FAT16, FAT32), exFAT, NTFS, HFS and HFS+, HPFS, APFS, UFS, ext2, ext3, ext4, XFS, Files-11, Veritas File System, VMFS, ZFS , and filesystems such as ReiserFS. In addition, the COPY ON WRITE technology can be implemented in software on the above file system.

The server 210 may select an initialization client. The server 210 may arbitrarily select an initialization client from among clients connectable to the server 210 . Also, the server 210 may select a predetermined client as an initialization client. The initiating client may be one of the at least one client 260 . The server 210 may control the initialization client to boot with the master image file. More specifically, the server 210 may connect the initialization client with the master image file. A storage area network (SAN) protocol or the like may be used to connect the initialization client and the master image file. The SAN protocol 250 may include at least one of Fiber Channel, Fiber Channel over Ethernet (FCoE), SCSI RDMA Protocol (SRP), Internet Small Computer Systems Interface (iSCSI), and Infiniband.

In addition, the initialization client may perform step 320 of obtaining a changed master image file by applying basic setting information to the master image file after booting to the master image file. The init client can boot into the master image file to set it up. An initialization client booted with the master image file can apply basic configuration information to the master image file. For example, the initialization client can install the OS to the master image file and install a program that analyzes malicious code. In addition, the initialization client can install programs that malicious code can act on or create files. When all settings of the initialization client are completed, the server 210 may acquire a changed master image file. The changed master image file may be stored in the first sub-volume. The changed master image file may be an image file that does not differ for each client.

The server 210 inherits the first sub-volume 220 containing the master image file changed by the COPY ON WRITE function, and creates a 1_k sub-volume that stores the changed master image file. . Here, k may be a natural number. The changed master image file may have a different version from the changed master image file. The system may create at least one re-modified master image of a different version than the altered master image file.

The init client can boot into the changed master image file and apply other preference information to the master image file. For example, the initialization client can install a different OS to the changed master image file and install a program that analyzes other malicious codes. In addition, the initialization client can install programs that malicious code can act on or create files. When all settings of the initialization client are finished, the server 210 may acquire a re-changed master image file. The re-modified master image file may be stored in the 1_k sub-volume. The re-modified master image file may be an image file that does not differ for each client. Also, the server 210 may generate a duplicate master image file using the re-modified master image file.

The user can create a re-modified master image file to test the changed master image file and a different environment on the same client. In addition, when the user wants to return the changed master image file to the changed master image file, the user can easily return to the previous one using the changed master image file stored in the first sub-volume. Hereinafter, a process of generating the m-th duplicate master image file stored in the n_1 th sub-volume 230 based on the changed master image file stored in the first sub-volume will be described. However, the same description may be applied to the process of generating the mth duplicate master image file stored in the n_1 th sub-volume 230 based on the re-modified master image file stored in the 1_k th sub-volume.

The server 210 inherits the first sub-volume 220 containing the changed master image file, and creates an n_1 th sub-volume 230 that stores the m-th duplicate master image file. Step 330 can be performed. have. Here, m may be a natural number. n may be a natural number of 2 or more. n=m+1.

The server 210 may create more than the number of sub-volumes of the clients 260 . The number of clients may be m. m may be a natural number. The server 210 may create a total of n sub-volumes including the first sub-volume 220 for storing the master image file and the n_1 th sub-volume 230 for storing the m-th duplicate master image file. Here, n may be a natural number of 2 or more. n=m+1.

The server 210 may allocate one replication master image file to each client 260 . For example, when the client 260 includes a first client 261 , a second client 262 , and a third client 263 , the server 210 may include a 2_1 sub-volume 231 , a 3_1 sub-volume 231 . A volume 232 and a 4_1 sub-volume 233 may be created. The 2_1 sub-volume 231, the 3_1 sub-volume 232, and the 4_1 sub-volume 233 may each include a first replication master image file, a second replication master image file, and a third replication master image file. have. The 2_1 sub-volume 231, the 3_1 sub-volume 232, and the 4_1 sub-volume 233 may correspond to the first client 261, the second client 262, and the third client 263, respectively. have. Hereinafter, the n_1 th sub volume 230 will be mainly described, but the same description may be applied to the 2_1 sub volume 231 , the 3_1 sub volume 232 , or the 4_1 sub volume 233 .

The n_1th sub-volume 230 may be created in the memory. The 2_1 sub-volume 231 , the 3_1 sub-volume 232 , and the 4_1 sub-volume may be created in the same memory as the first sub-volume. However, the present invention is not limited thereto, and the 2_1 sub-volume, the 3_1 sub-volume 232, and the 4_1 sub-volume may be created in a memory different from the first sub-volume.

The n_1th sub-volume 230 may succeed the first sub-volume 220 by the COPY ON WRITE technique. For example, the first sub-volume may be a parent volume, and the 2_1 sub-volume 231 , the 3_1 sub-volume 232 , and the 4_1 sub-volume 233 may be child volumes.

As already described, the server 210 may implement COPY ON WRITE technology. The m-th duplicate master image file stored in the n_1 th sub-volume 230 created initially may be the same as the changed master image file. In addition, the m-th duplicate master image file generated initially may include only information for referring to the changed master image file. Since the initially created mth replication master image file only includes information for referencing the changed master image file, the actual capacity occupied by the mth replication master image file on the disk may be smaller than the capacity of the changed master image file.

According to an embodiment of the present disclosure, when the m-th replication master image file is modified, the server 210 actually copies the file from the changed master image file and reflects the changed file to the m-th replication master image file after the change. can do. That is, the mth replication master image file may include the changed file. The mth duplicate master image file may actually include only files different from the "modified master image file". In this way, since only the part that is different from the original changed master image file is included in the duplicate master image file, it is possible to minimize writing of memory and save storage space. In addition, when using a memory with a limited number of writes, it is possible to reduce the maintenance cost by extending the life of the memory compared to the case where COPY ON WRITE technology is not applied.

According to various embodiments of the present disclosure, when the n_1 th sub-volume is modified, the server 210 may reflect only the changes from the first sub-volume to the n_1 th sub-volume. That is, the n_1 th sub-volume may include changed content. The n_1th sub-volume may actually include only content different from that of the first sub-volume. For example, the mth duplicate master image file included in the n_1th sub-volume may actually include only content different from the changed master image file included in the first sub-volume. As described above, since only a portion different from the original first sub-volume is included in the n_1 th sub-volume, memory writing can be minimized and storage space can be saved. In addition, when using a memory with a limited number of writes, it is possible to reduce the maintenance cost by extending the life of the memory compared to the case where COPY ON WRITE technology is not applied.

The server 210 may perform a step 340 of allocating the mth replication master image file included in the n_1th sub-volume to the client. The server 210 may use the storage area network (SAN) protocol 250 to allocate the mth replication master image file included in the n_1th sub-volume 230 to the client 260 . The SAN protocol 250 may include at least one of Fiber Channel, Fiber Channel over Ethernet (FCoE), SCSI RDMA Protocol (SRP), Internet Small Computer Systems Interface (iSCSI), and Infiniband. Hereinafter, description will be focused on using the iSCSI protocol. However, the same description can be applied even when other protocols are used.

The server 210 may generate information necessary for the iSCSI connection with respect to the mth replication master image file in the n_1th sub-volume 230 . For example, the server 210 may generate information required for iSCSI connection with respect to the m-th replication master image file in the 2_1 sub-volume 231 , the 3_1 sub-volume 232 , and the 4_1 sub-volume 233 , respectively. Here, the information required for the iSCSI connection may include at least one of a logical unit number (LUN), a network address and port of the iSCSI target, and identification information of the iSCSI target. The identification information of the iSCSI target may be information for identifying the iSCSI and may correspond to the iSCSI target. The identification information of the iSCSI target may include an iSCSI Qualified Name (IQN) or an Extended Unique Identifier (EUI). A LUN may be a number to identify a logical disk within an iSCSI target. One iSCSI target can have multiple LUNs.

The server 210 may allocate the m-th replication master image file included in the n_1 th sub-volume 230 to the client 260 by generating information necessary for the iSCSI connection. The information required for the iSCSI connection may include identification information of the iSCSI target. The number of iSCSI target identification information generated by the server 210 may be greater than or equal to the number of clients 260 . This is because one client can connect to at least one iSCSI target.

The number of iSCSI targets can be equal to or greater than the number of clients to use at the same time. Also, one client may connect to at least one iSCSI target.

The client 260 may transmit Dynamic Host Configuration Protocol (DHCP) request information to the server 210 . The server 210 may determine an IP address to be assigned to the client 260 in response to the DHCP request information. Also, the server 210 may match the IP address assigned to the client 260 with information required for the iSCSI connection. As already described, the information required for the iSCSI connection may include at least one of a LUN, a network address and port of an iSCSI target, and identification information of an iSCSI target.

The server 210 may transmit an IP address and information necessary for an iSCSI connection to the client 260 . The iSCSI target may be a kind of interface for memory input/output. The form of the iSCSI target may be the physical storage itself connected to the network, or it may be a service implemented by software running on the storage server. In addition to this, the iSCSI target may exist in various forms. For example, the iSCSI target may be a storage server included in the server 210 . The storage server may have separate and independent hardware, but is not limited thereto, and may share at least a part of hardware of the server 210 . The storage server may be a server including a large amount of memory. The client 260 may configure a network based on the IP address. Also, the client 260 may connect to the n_1 th sub-volume 230 based on information required for the iSCSI connection. The mth duplicate master image file in the n_1th sub-volume 230 may be used as a memory.

After the client 260 boots to the mth replication master image file included in the n_1th sub-volume 230, applying additional setting information to the mth replication master image file to obtain a changed mth replication master image file (350) ) can be done.

The client 260 may boot from the mth duplicate master image file included in the n_1th sub-volume. As already described, the m-th duplicate master image file initially created may be the same as the changed master image file. An OS and a program may be installed in the mth clone master image file. However, the client 260 may not operate properly because the driver for the client 260 is not installed in the mth replication master image file. Accordingly, the client 260 may apply additional setting information to the mth duplicate master image file. Applying additional configuration information may mean setting necessary for individual hardware, such as activating the program and installing drivers. The client 260 may acquire the changed m-th duplicate master image through this process.

For example, each of the first client 261 , the second client 262 , and the third client 263 included in the client 260 is a first replication master image file, a second replication master image file, and a second Each of the 3 replication master image files may be changed to generate a modified first replication master image file, a changed second replication master image file, and a modified third replication master image file. The changed first replication master image file, the changed second replication master image file, and the changed third replication master image file may be stored in the 2_1 sub-volume, the 3_1 sub-volume, and the 4_1 sub-volume, respectively.

The client 260 may create a modified clone master image file optimized for its own hardware. For example, the changed first replication master image file may be optimized for the hardware of the first client 261 . If the second client 262 is connected to the changed first replication master image file, the second client 262 may have to re-modify the changed first replication master image file to fit its own hardware. Of course, if the first client 261 and the second client 262 have the same hardware, it is separate from the fact that it may not be necessary to re-modify the changed first duplicate master image file. Also, even if you have different hardware, you may not need to re-modify if you do not need a separate hardware-dependent configuration.

In addition, the first client 261 , the second client 262 , and the third client 263 included in the client 260 use different settings even if they have the same hardware, and the changed first replication master image file, the changed A second replication master image file and a modified third replication master image file may be generated. Different settings can mean having different drivers, programs, and files. The malicious code analysis system may simultaneously analyze the operation of the malicious code in various environments using the first client 261 , the second client 262 , and the third client 263 included in the client 260 .

The malicious code analysis system may use the changed copy master image file for initialization of the client 260 . Even if the client 260 is contaminated to perform malicious code analysis, the malicious code analysis system may return the client 260 to the initial state based on the changed copy master image file. Also, the client 260 may perform malicious code analysis again in the initial state.

For example, the changed mth replication master image file may be an image file storing the initial state of the client 260 . For example, the modified first replication master image file, the modified second replication master image file, and the modified third replication master image file are the first client 261 , the second client 262 , and the third client 263 respectively. It may be an image file in which the initial state of When the image files used by the first client 261 , the second client 262 , and the third client 263 are contaminated during the malicious code analysis process, the malicious code analysis system converts the changed first duplicate master image The image files of the first client 261 , the second client 262 , and the third client 263 can be returned to their initial state by using the file, the changed second clone master image file, and the changed third clone master image file. have. Also, the malicious code analysis system may start to analyze a new malicious code using the first client 261 , the second client 262 , and the third client 263 returned to the initial state. This will be described in more detail with reference to FIGS. 4 to 5 .

The server 210 inherits the n_1 th sub-volume 230 containing the changed m-th replication master image file, and further creates an n_1_1 th sub-volume that stores the m_1 th replication master image file. The n_1_1 th sub-volume may correspond to each of the clients 260 . May include the m_1th replica master image file. The m_1th replication master image file may correspond to each of the clients 260 .

The server 210 may further create sub-volumes greater than or equal to the number of clients 260 . The server 210 may allocate one image file included in the sub-volume to each client 260 . For example, when the client 260 includes a first client 261 , a second client 262 , and a third client 263 , the server 210 may include a 2_1_1 sub-volume, a 3_1_1 sub-volume and a second client 263 . You can create 4_1_1 sub-volumes. The 2_1_1 th sub-volume, the 3_1_1 sub-volume, and the 4_1_1 sub-volume may include a 1_1 duplicate master image file, a 2_1 duplicate master image file, and a 3_1 duplicate master image file, respectively. The 2_1_1 sub-volume, the 3_1_1 sub-volume, and the 4_1_1 sub-volume may correspond to the first client 261 , the second client 262 , and the third client 263 , respectively. Hereinafter, the n_1_1 th sub-volume will be mainly described, but the same description may be applied to the 2_1_1 th sub-volume, the 3_1_1 sub-volume, or the 4_1_1 th sub-volume.

As already described, the COPY ON WRITE technology may be implemented in the server 210 . The m_1 th replication master image file stored in the initially created n_1_1 th sub-volume may be the same as the changed m th replication master image file. In addition, the initially generated m_1 th replication master image file may include only information for referring to the changed m th replication master image file. Since the initially created m_1th replication master image file only contains information for referencing the changed mth replication master image file, the actual capacity occupied by the mth replication master image file on the disk may be smaller than the capacity of the changed master image file. can

The n_1_1 th sub-volume may succeed the n_1 th sub-volume by the COPY ON WRITE technique. According to various embodiments of the present disclosure, when the n_1_1 th sub-volume is modified, the server 210 may reflect only the changes from the n_1 th sub-volume to the n_1_1 th sub-volume. That is, the n_1_1 th sub-volume may include changed content. The n_1_1 th sub-volume may actually include only content different from the n_1 th sub-volume. For example, the m_1 th replication master image file included in the n_1_1 th sub-volume may actually include only content different from the changed m th replication master image file included in the n_1 th sub-volume.

The server 210 may perform the step of allocating the m_1 th replication master image file included in the n_1_1 th sub-volume to the client. The client 260 may transmit Dynamic Host Configuration Protocol (DHCP) request information to the server 210 . The server 210 may determine an IP address to be assigned to the client 260 in response to the DHCP request information. Also, the server 210 may match the IP address assigned to the client 260 with information required for the iSCSI connection. The server 210 may transmit an IP address and information necessary for an iSCSI connection to the client 260 .

After booting with the m_1th replication master image file included in the n_1_1th sub-volume, the client 260 applies additional setting information to the m_1th replication master image file to obtain a changed m_1th replication master image file. have. The modified m_1st replication master image file may have a different version from the changed mth replication master image file. The system may perform the above method multiple times to generate at least one duplicate master image of a different version from the mth duplicate master image file. The user may create a changed m_1th replication master image file to test the environment different from the changed mth replication master image file on the same client. In addition, if the user wants to return the changed m_1th replication master image file to the changed mth replication master image file, the user can easily return to the previous using the changed mth replication master image file stored in the n_1th sub-volume.

As described above, the server 210 inherits the n_1 th sub-volume 230 containing the changed m-th replication master image file and creates the n_1_1 th sub-volume for storing the m_1 th replication master image file. Using the same process as above, the server 210 inherits the n_1_k-th sub-volume 230 containing the changed m_k-th replication master image file, and stores the m_(k+1)-th replication master image file, n_1_(k) +1) The step of creating more sub-volumes may be performed. Here, k may be a natural number.

Hereinafter, the client 260 will mainly describe using the changed m-th duplicate master image file to test the malicious code. However, the process for testing the malicious code can be equally described by using the changed m_k clone master image file instead of the changed mth clone master image file.

4 is a block diagram illustrating a server or a client according to an embodiment of the present disclosure. 5 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.

Hereinafter, a flowchart of the malicious code analysis system of FIG. 5 together with FIG. 4 will be described.

The server 210 inherits the n_1 th sub-volume 230 including the changed m th clone master image file, and creates an n_2 th sub-volume 240 that stores the m_1 th boot image file. Step 510 is performed. can do. Here, m may be a natural number. Also, n may be a natural number of 2 or more. N=m+1.

The n_2 th sub-volume 240 may succeed the n_1 th sub-volume 230 . The server 210 may create the n_2th sub-volume 240 on the n_1th sub-volume 230 by using the snapshot function of Btrfs. As already described, the snapshot function may mean a COPY ON WRITE function. The n_2 th sub-volume 240 may store the m_1 th boot image file.

The server 210 may further create sub-volumes greater than or equal to the number of clients 260 . The number of clients may be m. m may be a natural number. The server 210 may create a total of n+m or more sub-volumes including the first sub-volume 220, the n_1th sub-volume 230, and the n_2th sub-volume 240 for storing the master image file. . That is, at this time, if the number of clients to be used at the same time is m, the total number of sub-volumes is m corresponding to the n_2 sub-volume group, m corresponding to the n_1 sub-volume group, and at least m+n with 1 first sub-volume. Two subvolumes may be required. Also, as already described, if the n_1_k-th sub-volume is further created, the number of sub-volumes may be increased. Here, n may be a natural number of 2 or more. n=m+1. Also, k may be a natural number.

For example, when the client 260 includes a first client 261 , a second client 262 , and a third client 263 , the server 210 may include a second sub-volume 241 and a third sub-volume 3_2 A volume 242 and a 4_2 sub-volume 243 may be created. The 2_2 sub-volume 241 , the 3_2 sub-volume 242 , and the 4_2 sub-volume 243 may include a 1_1 boot image file, a 2_1 boot image file, and a 3_1 boot image file, respectively. Hereinafter, the n_2th sub-volume 240 will be mainly described, but the same description may be applied to the 2_2 sub-volume 241 , the 3_2 sub-volume 242 , or the 4_2th sub-volume 243 .

The n_2th sub-volume 240 may be created in the memory. 2_2 sub-volume 241, 3_2 sub-volume 242, and 4_2 sub-volume 243 are 2_1 sub-volume 231, 3_1 sub-volume 232, and 4_2 sub-volume 233 or It may be created in the same memory as the first sub-volume 220 . However, the present invention is not limited thereto, and the 2_1 sub-volume, the 3_2 sub-volume 242, and the 4_2 sub-volume 243 are the first sub-volume 220, the 2_1 sub-volume 231, and the 3_1 sub-volume ( 232), and the 4_1 sub-volume 233 may be created in a different memory.

The n_2th sub-volume 240 may succeed the n_1th sub-volume 230 by the COPY ON WRITE technique. Here, the n_1 th sub-volume 230 may be a parent volume, and the n_2 th sub-volume 240 may be a child volume. Also, if the n_1_1 th sub-volume is generated as described above, the n_2 th sub-volume 240 may inherit the n_1_1 th sub-volume by using the COPY ON WRITE technique. Hereinafter, the case where the n_2th sub-volume 240 succeeds the n_1th sub-volume 230 will be mainly described, but the same description can be applied to the case where the n_2th sub-volume 240 inherits the n_1_1th sub-volume. .

Referring to FIG. 4 , the 2_2 sub-volume 241, the 3_2 sub-volume 242, and the 4_2 sub-volume 243 are the 2_1 sub-volume 231 and the 3_1 sub-volume ( 232) and the 4_1th sub-volume 233 may be inherited, respectively. That is, the 2_1 sub-volume 231, the 3_1 sub-volume 232, and the 4_1 sub-volume 233 are parent volumes, and the 2_2 sub-volume 241, the 3_2 sub-volume 242, and the 4_2 sub-volume are Volume 243 may be a child volume. Also, if necessary, the server 210 may create an n_k-th sub-volume by inheriting the n_2th sub-volume 240 . Through this process, it is possible to quickly and stably analyze malicious codes while reducing the reading and writing of data to the sub-volumes.

As already described, the server 210 may implement COPY ON WRITE technology. The m_1 th boot image file initially created in the n_2 th sub-volume 240 may be the same as the changed m th duplicate master image file. In addition, the initially generated m_1 th boot image file may include only information for referring to the changed m th clone master image file. Since the initially generated m_1 th boot image file only includes information for referencing the changed m th clone master image file, the capacity of the m_1 th boot image file may be smaller than the capacity of the changed m th clone master image file.

According to an embodiment of the present disclosure, when the m_1 th boot image file is modified, the server 210 actually copies the corresponding file from the changed m th clone master image file and reflects the changed file to the m_1 th boot image file after the change. can do. That is, the m_1 th boot image file may include the changed file. The m_1 th boot image file may actually include only a file different from the changed m th clone master image file.

According to various embodiments of the present disclosure, when the n_2th sub-volume is modified, the server 210 may reflect only the changes from the n_1th sub-volume to the n_2th sub-volume. That is, the n_2th sub-volume may include changed content. The n_2 th sub-volume may actually include only content different from the n_1 th sub-volume. For example, the m_1 th boot image file included in the n_2 th sub volume may actually include only content different from the changed m th duplicate master image file included in the n_1 th sub volume.

The server 210 may perform an operation 520 of allocating the m_1th boot image file included in the n_2th sub-volume 240 to the client 260 . The server 210 may use the SAN protocol 250 to allocate the m_1 th boot image file in the n_2 th sub-volume 240 to the client 260 . The SAN protocol 250 may include at least one of Fiber Channel, Fiber Channel over Ethernet (FCoE), SCSI RDMA Protocol (SRP), Internet Small Computer Systems Interface (iSCSI), and Infiniband. Hereinafter, description will be focused on using the iSCSI protocol. However, the same description can be applied even when other protocols are used.

The server 210 may generate information necessary for iSCSI connection with respect to the m_1 th boot image file in the n_2 th sub volume 240 . The server 210 configures the first boot image file, the second_1 boot image file, and the third_1 boot image file in the 2_2 sub-volume 241, the 3_2 sub-volume 242, and the 4_2 sub-volume 243, respectively. You can create the necessary information for the iSCSI connection. Here, the information required for the iSCSI connection may include at least one of a logical unit number (LUN), a network address and port of the iSCSI target, and identification information of the iSCSI target. The identification information of the iSCSI target may include an iSCSI Qualified Name (IQN) or an Extended Unique Identifier (EUI). A LUN may be a number to identify a logical disk within an iSCSI target.

The client 260 may transmit DHCP request information to the server 210 . The server 210 may determine an IP address to be assigned to the client 260 in response to the DHCP request information. Also, the server 210 may match the IP address assigned to the client 260 with information required for the iSCSI connection. The server 210 may transmit an IP address and information necessary for an iSCSI connection to the client 260 . The iSCSI target may be a storage server included in the server 210 . The storage server may be a server including a large amount of memory. The client 260 may configure a network based on the IP address. In addition, the client 260 may connect to the n_2 th sub-volume 240 based on the iSCSI target address and use the m_1 th boot image file in the n_2 th sub-volume 240 as a memory.

The client 260 performs malicious code analysis after booting with the m_1th boot image file included in the n_2th sub-volume 240, and transmits the malicious code analysis result related to the contaminated m_1st boot image file to the server 210. Step 530 may be performed.

The first client 261 may perform malicious code analysis after booting with the 1_1 boot image file included in the 2_2 sub-volume 241, and transmit the malicious code analysis result related to the contaminated 1_1 boot image file to the server. . In addition, the second client 262 performs malicious code analysis after booting with the 2_1 boot image file included in the 3_2 sub-volume 242, and transmits the malicious code analysis result related to the contaminated 2_1 boot image file to the server. have. The third client 263 may perform malicious code analysis after booting with the 3_1 boot image file included in the 4_2 sub-volume 243 , and transmit a malicious code analysis result related to the contaminated 3_1 boot image file to the server.

Analyzing the malicious code may mean that the client 260 is infected with the malicious code and records the operation of the malicious code as a log file. Therefore, the m_1th boot image file may be corrupted.

The client 260 may transmit the analysis result to the server 210 . The analysis result may be log data indicating the operation of the malicious code. In order for the client 260 to analyze the malicious code, the m_1 th boot image file included in the n_2 th sub-volume 240 is contaminated by the malicious code. The server 210 may initialize the n_2th sub-volume 240 including the corrupted m_1th boot image file. That is, the server 210 may initialize the 2_2 sub-volume 241 including the contaminated 1_1 boot image file. Also, the server 210 may initialize the 3_2 sub-volume 242 including the corrupt 2_1 boot image file. Also, the server 210 may initialize the 4_2 th sub-volume 243 including the corrupt 3_1 boot image file. In order to initialize the n_2th sub-volume 240 , the server 210 deletes the n_2 sub-volume 240 and copies the n_1 sub-volume 240 using a snapshot function to re-create the n_2 sub-volume 240 . The snapshot function may correspond to the COPY ON WRITE function.

The client 260 may perform malicious code analysis for a predetermined period of time. Here, the predetermined time may be input by a system administrator or received from an external device. The malicious code analysis program executed by the client 260 may include a series of commands for deriving a malicious code analysis result. When the malicious code analysis result is derived by the client 260 executing a series of commands of the malicious code analysis program within a predetermined time, the client 260 may transmit the analysis result to the server 210 . Thereafter, the server 210 may restart or terminate the client 260 to initialize the n_2 th sub-volume 240 . Also, when the client 260 fails to execute all of a series of commands of the malicious code analysis program even after a predetermined time has elapsed, the client 260 may transmit the analysis results collected so far to the server 210 . The analysis results collected so far may include information indicating that all a series of commands of the analysis program have not been executed. After that, the server 210 may forcefully restart or terminate the client 260 to initialize the n_2th sub-volume 240 . If the client 260 does not complete the analysis within a predetermined time after starting the analysis, the server 210 terminates or reboots the client 260 to prevent the malicious code from being continuously executed in the client 260 . can do. Therefore, the malicious code system can prevent side effects or power wastage caused by the malicious code.

The server 210 may terminate or reboot the client 260 to initialize the n_2 th sub-volume 240 including the m_1 th boot image file that is contaminated. When the client 260 is terminated, the server 210 may transmit a start signal to the client 260 so that the client 260 is restarted. During the process of booting or rebooting the client 260 , the n_2 th sub-volume 240 including the corrupt m_1 th boot image file may be initialized.

A process in which the server 210 initializes the n_2th sub-volume 240 will be described with reference to FIG. 6 .

6 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure. 7 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.

The client 260 may perform step 631 of transmitting a first Dynamic Host Configuration Protocol (DHCP) request to the server 210 . The steps of FIGS. 6 and 7 may be performed while the client 260 boots or reboots. For example, the power of the client 260 may be turned on according to a command from the server 210 or a user in order to analyze the malicious code while the power is turned off. In addition, after the client 260 analyzes the malicious code, the server 210 may transmit a reboot command to the client 260 to initialize the corrupted boot image corresponding to the client 260 . The power of the client 260 may be temporarily turned off and then turned on again based on a reboot command from the server 210 . Client 260 may begin performing the steps of FIGS. 6 and 7 . For example, when power is turned on again to the client 260 , the client 260 may perform an operation 631 of transmitting a first DHCP request to the server 210 .

The client 260 may transmit the first DHCP request through broadcasting because the network is not set.

The server 210 may perform step 632 of determining the first network configuration information of the client 260 . The first network setting information may include at least one of an IP address to be assigned to the client 260 and a location of a Preboot Execution Environment (PXE) firmware image. For example, the server 210 may determine an IP address to be assigned to the client 260 among available IP addresses. In addition, the server 210 may determine an address indicating the location of the PXE firmware image. The PXE firmware image location may be predetermined. Also, the server 210 may select one PXE firmware image from among a plurality of PXE firmware images based on the identification information of the client 260 received from the client 260 and determine the location of the selected PXE firmware image.

The server 210 may perform step 633 of transmitting the first network setting information to the client 260 . The client 260 may perform an operation 634 of setting up a network based on the first network setting information. For example, the client 260 may set at least one of an IP address, a DNS server, and a gateway address based on the first network setting information. The client 260 may send/receive data to and from the server 210 using TCP/IP or UDP protocol after network setting is completed.

The client 260 may perform an operation 635 of transmitting Preboot Execution Environment (PXE) firmware request information to the server 210 based on the first network setting information. As already described, the first network setting information may include the location of the PXE firmware image. The client 260 may request the PXE firmware from the server 210 based on the PXE firmware location. The server 210 may include at least one server having independent hardware. Alternatively, the server 210 may include at least one server sharing at least a part of hardware. Since the client 260 transmits the location of the PXE firmware to the server 210 in order to request the PXE firmware image, the server 210 may know the location of the PXE firmware image among at least one server.

The client 260 may transmit PXE firmware request information using Trivial File Transfer Protocol (TFTP). The PXE firmware request information may be a READ REQUEST (RRQ) of the TFTP protocol. TFTP (Trivial File Transfer Protocol) is a protocol used by an arbitrary system to download booting code from a remote system. That is, a client that does not have its own hard disk downloads the boot image stored in the server 210 over the network and uses it to initialize the system. The remote booting may be implemented as a simple transmission function because a complicated file operation is not separately required in the server 210 . That is, the task performed by the TFTP is to copy the PXE firmware image file, which is one file, from the server 210 to the client 260 .

The PXE firmware image file may be included in the server 210 , but is not limited thereto. The PXE firmware image may be stored in an external PXE server. Alternatively, the PXE firmware image may be stored in a PXE server that shares at least a part of hardware of the server 210 . In this case, the client 260 may request the PXE firmware from the PXE server based on the location of the PXE firmware image included in the first network setting information.

The server 210 may perform step 636 of transmitting the PXE firmware image file to the client 260 . The server 210 may transmit the PXE firmware image file to the client 260 using the TFTP protocol.

The server 210 may further perform the following steps before performing the step of transmitting the PXE firmware image file to the client.

The server 210 may perform step 640 of initializing the boot image file corresponding to the client 260 . The boot image file may include an m_1 boot image file and an m_2 boot image file. In order to describe the step 640 of initializing the boot image file, reference is made briefly to FIG. 8 .

8 is a flowchart illustrating an operation of a malicious code analysis system according to an embodiment of the present disclosure.

The steps of FIG. 8 may be included in the step 640 of initializing the boot image file of FIG. 6 .

The server 210 may perform an operation 810 of disconnecting the connection between the client 260 and a storage area network (SAN) logical unit number (LUN). Here, the SAN LUN may include an iSCSI LUN. The following description focuses on iSCSI, but the same description can be applied to other protocols included in the SAN. As already described, since the client 260 is rebooting or booting, the connection to the iSCSI target may be released. The server 210 may delete the LUN of the iSCSI target corresponding to the client 260 . The server 210 may prevent the client 260 from reconnecting to the iSCSI target by deleting the LUN of the iSCSI target corresponding to the client 260 . Also, the server 210 may control the client 260 to connect to the iSCSI after initialization of the n_2 sub-volume 240 is completed.

In the process of analyzing the malicious code by the client 260 , the server 210 deletes the m_1th boot image file that is contaminated in step 820 . Alternatively, the server 210 may delete the n_2th sub-volume 240 in which the m_1th boot image file is stored.

The server 210 may perform an operation 830 of generating a new m_2 th boot image file corresponding to the client 260 based on the changed m th replication master image file. Alternatively, the server 210 may perform the step of re-creating the n_2 th sub-volume 240 based on the n_1 th sub-volume 230 . The n_2 th sub-volume 240 may be regenerated based on the n_1 th sub-volume 230 by the COPY ON WRITE technique. The m_2 th boot image may be stored in the n_2 th sub volume 240 . The m_2 th boot image may be the same as the changed m th clone master image file. The m_2th boot image may be a boot image that is not contaminated with malicious code.

For example, the 2_2 sub-volume 241 may be regenerated based on the 2_1 sub-volume 231 . The 2_2 sub-volume 241 may include a 1_2 boot image. The 3_2 sub-volume 242 may be regenerated based on the 3_1 sub-volume 232 . The 3_2 sub-volume 242 may include a 2_2 boot image. The 4_2th sub-volume 243 may be regenerated based on the 4_1th sub-volume 233 . The 4_2 th sub-volume 243 may include a 3_2 th boot image.

The server 210 may perform an operation 840 of allocating the m_2 th boot image file to the client. The server 210 may create a new LUN using the regenerated n_2 th sub-volume 240 as a backing-store. For example, the server 210 may create a new LUN for the m_2th boot image file stored in each of the regenerated 2_2 sub-volume 241, 3_2 sub-volume 242, and 4_2 sub-volume 243. . 1_2 boot image file, 2_2 boot image file, and 3_2 boot image file stored in the regenerated 2_2 sub-volume 241, 3_2 sub-volume 242, and 4_2 sub-volume 243 are stored in the first client ( 261 ), the second client 262 , and the third client 263 , respectively.

Referring back to FIG. 6 , when the initialization of the boot image file corresponding to the client 260 is completed, the server 210 may perform an operation 636 of transmitting the PXE firmware image file to the client 260 .

In addition, if the initialization of the boot image file corresponding to the client 260 is not completed, the server 210 does not transmit the PXE firmware image file to the client 260 and waits until the initialization is completed. can When an error occurs during initialization, the server 210 may perform initialization again. Also, when an error occurs during initialization, the server 210 may transmit error-related information to the user's terminal using wired/wireless communication. The user terminal may include a user's PC, smartphone, tablet, and the like. The information related to the error may include at least one of information about whether an error has occurred, information about the content of the error, and information about an error occurrence time. Users can check information related to errors and take necessary actions quickly.

The client 260 may perform booting ( 637 ) based on the PXE firmware image file. The client 260 may make basic preparations to connect to the LUN of the iSCSI target using the PXE firmware image file. The plurality of clients 261 , 262 , and 263 included in the client 260 may be booted by the PXE firmware image file to be in a state for booting into the OS. The plurality of clients 261 , 262 , and 263 included in the client 260 may be booted by the PXE firmware image file and put into a state for connecting to the LUN of the iSCSI target. The server 210 transmits the PXE firmware image file to the plurality of clients 261, 262, and 263 without having to individually control the plurality of clients 261, 262, and 263 to boot the OS to the client 260. can automatically boot the OS. Hereinafter, an operation method of the malicious code analysis apparatus will be further described with reference to FIG. 7 .

Referring to FIG. 7 , the client 260 may perform an operation 731 of transmitting a second DHCP request to the server 210 . The client 260 may send a second DHCP request to the server 210 by broadcasting. However, the present invention is not limited thereto, and the client 260 may transmit the second DHCP request to the address of the server 210 .

The server 210 may perform an operation 732 of determining the second network configuration information of the client 260 . The second network setting information may include at least one of an IP address and information required for an iSCSI connection. Here, the information required for the iSCSI connection may mean information required for the client 260 to connect to the m_1 th boot image file in the n_2 th sub volume 240 corresponding to the client 260 . In addition, the information required for the iSCSI connection may include at least one of a logical unit number (LUN), a network address and port of the iSCSI target, and identification information of the iSCSI target. The identification information of the iSCSI target may include an iSCSI Qualified Name (IQN) or an Extended Unique Identifier (EUI). A LUN may be a number to identify a logical disk within an iSCSI target.

The server 210 may allocate a new IP address of the client 260 . Also, the server 210 may determine information required for the iSCSI connection allocated to the client 260 . The server 210 may allocate information required for each iSCSI connection to at least one client included in the client 260 . Information required for each iSCSI connection allocated to at least one client may be different. That is, information required for an iSCSI connection with at least one client can correspond one-to-one.

The server 210 may perform step 733 of transmitting the second network setting information to the client 260 . The client 260 may perform an operation 734 of setting up a network based on the second network setting information. Step 734 of setting up a network may be the same/similar to step 634 of setting up a network.

The client 260 may perform an operation 735 of connecting to a storage area network (SAN) target based on the second network configuration information. The SAN can be one of Fiber Channel, Fiber Channel over Ethernet (FCoE), SCSI RDMA Protocol (SRP), iSCSI, or Infiniband. That is, the SAN target may be an iSCSI target. Hereinafter, iSCSI will be mainly described, but the same description may be applied to other protocols. The client 260 may be connected to the m_1 boot image stored in the n_2 sub-volume 240 .

The iSCSI target may be a storage server included in the server 210 or may exist in the corresponding server. The iSCSI target may be a kind of interface for memory input/output. The form of the iSCSI target may be the physical storage itself connected to the network, or it may be a service implemented in software running on the storage server.

The storage server may have separate and independent hardware, but is not limited thereto, and may share at least a part of hardware of the server 210 . The storage server may be a server including a large amount of memory. Also, the client 260 may connect to the boot image stored in the sub-volume of the server 210 based on information required for the iSCSI connection. The client 260 may use the boot image of the sub-volume of the server 210 as a memory. That is, the client 260 may use the m_2th boot image file in the n_2th sub-volume 240 of the server 210 as a memory. For example, the first client 261 may be connected to the first_2 boot image file in the second_2 sub-volume 241 . The 2_2 sub-volume 241 may store the 1_2 boot image file. The 1_2 boot image file may be a clean boot image generated based on the changed first duplicate master image file of the 2_1 sub-volume 231 after the contaminated 1_1 boot image is deleted. The second client 262 may be connected to the 2_2 boot image file in the 3_2 sub-volume 242 . The 3_2 sub-volume 242 may store the 2_2 boot image file. The third client 263 may be connected to the 3_2 boot image file in the 4_2 sub-volume 243 . The 4_2 th sub-volume 243 may store a 3_2 th boot image file.

The client 260 may perform booting ( 736 ) based on the m_2 th boot image file allocated to the iSCSI LUN. The connection of the client 260 to the iSCSI LUN may mean that the client 260 is connected to the m_2 boot image stored in the n_2 th sub-volume 240 through a network. The connection of the client 260 to the iSCSI LUN may mean that the client 260 uses the m_2 boot image stored in the n_2 th sub-volume 240 as a memory. Through the iSCSI target, memory Input/Output of the client 260 may be made through a network.

The first client 261 may be ready to analyze a new malicious code based on the 1_2 boot image file included in the 2_2 sub-volume 241 . Also, the second client 262 may be ready to analyze a new malicious code based on the 2_2 boot image file included in the 3_2 sub-volume 242 . Also, the third client 263 may be ready to analyze a new malicious code based on the 3_2 boot image file included in the 4_2 sub-volume 243 .

The malicious code analysis system may perform malicious code analysis using a plurality of clients 261 , 262 , and 263 . In the malicious code analysis process, the 1st_2 boot image, the 2_2 boot image, and the 3_2 boot image of the plurality of clients 261 , 262 , and 263 may be contaminated again. The malicious code analysis system may initialize the boot image by performing the same process as in FIGS. 6 and 7 again.

Meanwhile, the above-described embodiments of the present invention can be written as a program that can be executed on a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable recording medium. The computer-readable recording medium includes a storage medium such as a magnetic storage medium (eg, a ROM, a floppy disk, a hard disk, etc.) and an optically readable medium (eg, a CD-ROM, a DVD, etc.).

So far, various embodiments have been mainly looked at. Those of ordinary skill in the art to which the present invention pertains will understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments are to be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims (11)

In the operating method of a malicious code analysis system using a bare metal sandbox,
sending, by the client, a first Dynamic Host Configuration Protocol (DHCP) request to the server;
determining, by the server, first network configuration information of the client;
sending, by the server, the first network setting information to the client;
transmitting, by the client, Preboot Execution Environment (PXE) firmware request information to the server based on the first network setting information;
sending, by the server, a PXE firmware image file to the client;
booting by the client based on the PXE firmware image file;
sending, by the client, a second DHCP request to the server;
determining, by the server, second network configuration information of the client;
connecting, by the client, to a storage area network (SAN) target based on the second network configuration information; and
and booting the client based on the m_2 th boot image file included in the SAN target.
The method of claim 1,
The step of the server sending the PXE firmware image file to the client comprises:
initializing, by the server, a boot image file corresponding to the client; and
and transmitting, by the server, a PXE firmware image file to the client when initialization of the boot image file corresponding to the client is completed.
The method of claim 1,
Transmitting the PXE firmware request information to the server and transmitting the PXE firmware image file to the client are performed based on a Trivial File Transfer Protocol (TFTP) protocol,
The method of operating a malicious code analysis system, characterized in that transmitting the PXE firmware request information to the server is a READ REQUEST (RRQ) of a TFTP protocol.
3. The method of claim 2,
The step of the client sending a first DHCP request to the server comprises:
sending, by the server, a reboot command to the client; and
when the client is powered on again, the client sending the first DHCP request to the server;
Initializing the boot image file includes:
disconnecting, by the server, the connection between the client and the SAN LUN;
deleting, by the server, the corrupted m_1st boot image file after analyzing the malicious code by the client;
generating, by the server, a new m_2th booting image file corresponding to the client based on the changed mth replication master image file; and
and allocating the m_2th boot image file to the client.
3. The method of claim 2,
and if the initialization of the boot image file corresponding to the client is not completed, the server does not transmit the PXE firmware image file to the client and waits until the initialization is completed.
5. The method of claim 4,
generating, by the server, a master image file after the first sub-volume is created;
obtaining, by an initialization client, a changed master image file by applying basic setting information to the master image file after booting to the master image file;
generating, by the server, an n_1 th sub-volume that inherits the first sub-volume containing the changed master image file and stores the m-th duplicate master image file;
allocating, by the server, the mth replication master image file included in the n_1th sub-volume to the client; and
After the client boots to the m-th clone master image file included in the n_1 sub-volume, applying additional setting information to the m-th clone master image file to obtain the changed m-th clone master image file How code analysis systems work.
7. The method of claim 6,
generating, by the server, an n_2th sub-volume that inherits the n_1 th sub-volume including the changed m-th clone master image file and stores the m_1 th boot image file;
allocating, by the server, the m_1 th boot image file included in the n_2 th sub-volume to the client; and
and performing malicious code analysis after the client boots with the m_1 th boot image file included in the n_2 th sub-volume, and transmitting the malicious code analysis result related to the contaminated m_1 th boot image file to the server. How the analysis system works.
7. The method of claim 6,
The first sub-volume and the n_1th sub-volume are generated on a file system that supports the COW (COPY ON WRITE) function, or a malicious code generated on a file system that does not support the COW function but has the COW function implemented in software. How the analysis system works.
generating, by the server, a master image file after the first sub-volume is created;
obtaining, by an initialization client, a changed master image file by applying basic setting information to the master image file after booting to the master image file;
generating, by the server, an n_1 th sub-volume that inherits the first sub-volume containing the changed master image file and stores the m-th duplicate master image file;
allocating, by the server, the mth replication master image file included in the n_1th sub-volume to a client; and
and acquiring, by the client, a changed mth duplicated master image file by applying additional setting information to the mth duplicated master image file after booting with the mth duplicated master image file included in the n_1th sub-volume How the analysis system works.
10. The method of claim 9,
generating, by the server, an n_2 th sub-volume that inherits the n_1 th sub-volume including the changed m th replication master image file and stores the m_1 th boot image file;
allocating, by the server, the m_1 th boot image file included in the n_2 th sub-volume to the client; and
The method further comprising the step of the client performing malicious code analysis after booting with the m_1st boot image file included in the n_2th sub-volume, and transmitting a malicious code analysis result related to the contaminated m_1th booting image file to the server How the malware analysis system works.
11. The method of claim 10,
sending, by the client, a first Dynamic Host Configuration Protocol (DHCP) request to the server;
determining, by the server, first network configuration information of the client;
sending, by the server, the first network setting information to the client;
transmitting, by the client, Preboot Execution Environment (PXE) firmware request information to the server based on the first network setting information;
sending, by the server, a PXE firmware image file to the client;
booting by the client based on the PXE firmware image file;
sending, by the client, a second DHCP request to the server;
determining, by the server, second network configuration information of the client;
connecting, by the client, to a storage area network (SAN) target based on the second network configuration information; and
and booting the client based on the m_2 th boot image file included in the SAN target.

Images