CN105160259A - Fuzzy testing based virtualized vulnerability mining system and method - Google Patents
Fuzzy testing based virtualized vulnerability mining system and method Download PDFInfo
- Publication number
- CN105160259A CN105160259A CN201510626457.8A CN201510626457A CN105160259A CN 105160259 A CN105160259 A CN 105160259A CN 201510626457 A CN201510626457 A CN 201510626457A CN 105160259 A CN105160259 A CN 105160259A
- Authority
- CN
- China
- Prior art keywords
- module
- submodule
- fuzz testing
- virtual machine
- abnormal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
Abstract
A fuzzy testing based virtualized vulnerability mining system comprises a physical server and a computer service station, wherein the physical server is communicated with the computer service station through the internet; a basic virtualized platform is arranged on the physical server, a first layer of virtual machine is arranged on the basic virtualized platform, and a second layer of virtual machine is arranged on the first layer of virtual machine; a fuzzy testing monitor module is arranged on the first layer of virtual machine, and a fuzzy testing module is arranged on the second layer of virtual machine; and the fuzzy testing monitor module monitors a running state of the fuzzy testing module, and the fuzzy testing module mainly finishes detection of virtualized vulnerabilities. The system has the advantages that possibly existent vulnerabilities in the virtualized platform can be discovered in time and repair opinions are provided for producers, so that the security of the virtualized platform can be improved.
Description
Technical field
The present invention relates to filed of network information security, particularly relate to a kind of virtual vulnerability mining system and method based on fuzz testing.
Background technology
Fuzz testing: fuzz testing is the concrete technology of one of Black-box Testing, more and more comes into one's own in security test.Its principle is input in target program by a large amount of lopsided data, found the security breaches that may exist in tested program by the exception of monitoring tested program.It is a typical automatic or automanual process.
Along with the progress of science and technology, increasing large enterprise or laboratory trend towards using virtualization architecture to save server cost or to improve application flexibility.Virtualized essence utilizes numerous virtual machines to replace original physical machine to carry out work in every.In virtual platform, each user does not need a whole set of hardware device, only needs a terminal presentation facility.Virtual machine runs on the server, is distributed to the user needing to use virtual machine by server.
Intel Virtualization Technology is a kind of resource management techniques, is by the various actual resources of computing machine, give abstract, conversion after present, break indivisible obstacle between physical mechanism, improve resource utilization, improve efficiency of operation.Virtual machine (VirtualMachine, VM) is the one of Intel Virtualization Technology, and VM refers to the software simulating of the computing machine that can run application as actual physical machine.
In order to make full use of resource, can install the virtual machine simulated by software virtual machine on the server, i.e. server in logic, in this virtual machine operational process, user as the operation to actual physical machine, can operate virtual machine.But under normal circumstances, virtual machine not the moment can all keep normal operation, the inevitable operation exception occurring extremely and cause because of code vulnerabilities, these are abnormal as can not Timeliness coverage processing, virtual machine then can be caused to be in abnormal operating condition, affect normally carrying out of work, also can bring certain economic loss to operator simultaneously.
Therefore, a kind of technology initiatively excavating virtual machine leak is needed to solve prior art Problems existing.
Summary of the invention
The object of the invention is for the deficiencies in the prior art, a kind of virtual vulnerability mining method and system based on fuzz testing is proposed, the leak that may exist in this system energy Timeliness coverage virtual platform also provides repairing suggestion for manufacturer, can increase the security of virtual platform.
A kind of virtual vulnerability mining system based on fuzz testing of the present invention comprises a physical server and a Computer Service station, and described physical server and Computer Service station realize interconnecting by internet;
Described physical server is furnished with underlying virtualizing platform, underlying virtualizing platform is arranged one deck virtual machine, one deck virtual machine arranges two-layer virtual machine again; Described one deck virtual machine is furnished with fuzz testing monitoring module, two-layer virtual machine is furnished with fuzz testing module; Wherein, the running status of described fuzz testing monitoring module monitoring fuzz testing module, described fuzz testing module mainly completes the detection to virtual leak;
Described Computer Service station is furnished with abnormal collection module, data memory module and display module; Wherein, described abnormal collection module mainly collects abnormal information from fuzz testing monitoring module, is also responsible for the monitoring to physical server simultaneously; Described data memory module is mainly used in storing and analyzing abnormal information; Described display module is mainly used in showing various crash info.
Described fuzz testing monitoring module is mainly monitored the object carrying out fuzz testing, and it mainly comprises virtual machine monitoring submodule, host monitoring submodule, information submodule and communicator module 4 function sub-modules; Wherein,
Described virtual machine monitoring submodule mainly monitors the unusual condition that when fuzz testing carries out, virtual machine may occur; Described host monitoring submodule mainly monitors one deck virtual machine hardware occupation condition; Described information submodule is responsible for the information of collecting one deck virtual machine and two-layer virtual machine, and all kinds of host informations of described collection will pass to abnormal collection module by communicator module; Described communicator module in charge intermediate communication, upwards by information submodule collect information, cause the status information of abnormal input information and one deck virtual machine and two-layer virtual machine to send to abnormal collection module; Communicate with information submodule downwards and collect information.
Described fuzz testing module comprises finger daemon submodule and test submodule; Wherein said finger daemon submodule is responsible for sending information to fuzz testing monitoring module and being responsible for producing stochastic inputs; Described finger daemon submodule is responsible for comprising in fuzz testing monitoring module transmission information and is caused abnormal input last time or the test after executing once test to complete message, described stochastic inputs is that described mistake input will be supplied to test submodule and use according to all kinds of mistake input of virtual platform parts stochastic generation; Described test submodule is the test process generated separately for each assembly virtual, and the stochastic inputs of described finger daemon submodule passes to test submodule by the mode shared between process.
Described abnormal collection module comprises data communication submodule and heartbeat submodule; Wherein, the operation of described heartbeat submodule primary responsibility management and control physical server, described heartbeat submodule comprises two links, one is positioned on physical server, another be positioned at abnormal collection module is installed computer workstation on, and two links are arranged in different computer workstations and energy UNICOM mutually, carry out heart-beat test at a certain time interval; Described data traffic module in charge is monitored the connection of fuzz testing monitoring module and is collected abnormal information and be responsible for abnormal information stored in data memory module.
Described data storage module comprises sub module stored and data analysis submodule; Wherein, described sub module stored is responsible for storing various information with the form of non-mechanism and being responsible for providing read-write interface; Described data analysis submodule is responsible for analyzing and provide miscue or prompting exception error file path to abnormal information.
A kind of above-mentioned method realizing virtual vulnerability mining based on the virtual vulnerability mining system of fuzz testing is utilized to comprise workflow, fuzz testing module work flow process, fuzz testing monitoring module workflow and abnormal collection module engineering process three part; Wherein,
Described workflow step is:
Step 1: start abnormal collection module;
Step 2: the IPMI interface remote that abnormal collection module is provided by server starts physical server;
Step 3: after physical server start, set up heartbeat with abnormal collection module and be connected, and automatically start underlying virtualizing platform, open one deck virtual machine;
Step 4: fuzz testing monitoring module starts automatically with after one deck virtual machine activation;
Step 5: fuzz testing is monitored and started (or restarting) two-layer virtual machine, the fuzz testing module start in two-layer virtual machine starts automatically, and the first thing after the unlatching of fuzz testing module sends input last time to fuzz testing monitoring module;
Step 6: fuzz testing module produces an input and saves, and then performs test; If two-layer virtual machine does not collapse, fuzz testing module sends a test to fuzz testing monitoring module and completes message, if cause exception, fuzz testing monitoring module meeting autoboot two-layer virtual machine, jump to step 5, otherwise proceed test next time after waiting for 12 seconds, rebound step 6;
Step 7: if one deck virtual machine crashes, underlying virtualizing platform autoboot two-layer virtual machine, skips to step 4;
Step 8: if physical server collapse, abnormal collection module can monitor, and then utilizes remote control panel autoboot server, rebound step 1;
Step 9: abnormal collection module is by all kinds of collection information stored in data memory module, and data memory module, to collection data analysis, is sent to display module;
Step 10: display module shows exception error information, platform information etc.;
Described fuzz testing module work flow process is:
Step 1: finger daemon submodule starts with the start of two-layer virtual machine, and first last fuzz testing being performed content after startup sends to fuzz testing monitoring module, and this input is kept in a local security file;
Step 2: for different test suite, tests submodule initialization accordingly;
Step 3: produce a stochastic inputs for test suite in step 2, and be saved to local security file;
Step 4: a new generation process, performs test submodule;
Step 5: send test to fuzz testing monitoring module and complete message;
Step 6: wait for certain hour, fuzz testing monitoring module monitoring host and virtual machine state, if there is exception, fuzz testing monitoring module directly can restart virtual machine, then skips to step 1, otherwise skips to step 3 continuation execution;
Described fuzz testing monitoring module workflow is:
Step 1: initialization information collects submodule, according to configuration file, collects corresponding tested virtualisation component information, as VMM type, version, host dummy machine system version etc.; That abnormal collection module is together issued in these information and abnormal input when generation is abnormal;
Step 2: start two-layer virtual machine by Virtual Machine Manager interface;
Step 3: set up UDP and monitor, receiving the message sent from fuzz testing module, if certain hour is for receiving message, then restarting two-layer virtual machine; Extremely input message if received, be then sent to abnormal collection module together with the information of abnormal input and information submodule being collected; If receive test to complete message, then check virtual machine and host state by virtual machine monitoring submodule, host monitoring submodule, if occur abnormal, then restart two-layer virtual machine;
Described abnormal collection module workflow is:
Step 1: start heartbeat submodule, heartbeat submodule sets up the message of UDP monitoring from physical server end, and heartbeat occurs once, if exceed certain hour section with certain hour section, then think that physical server is abnormal, then restart physical server by IPMI interface;
Step 2: physical server heartbeat service is opened, and to heartbeat submodule generation heartbeat packet;
Step 3: set up UDP monitoring from the connection of each fuzz testing monitoring module, if there is unexpected message to send over, according to the type of abnormal information, write in data memory module by data communication submodule.
The invention has the advantages that: the leak that may exist in system energy Timeliness coverage virtual platform of the present invention also provides repairing suggestion for manufacturer, can increase the security of virtual platform.
Accompanying drawing explanation
Fig. 1 is a kind of virtual vulnerability mining entire system configuration diagram based on fuzz testing.
Embodiment
For making the object, technical solutions and advantages of the present invention clearly understand, hereafter will be described in further detail technical solution of the present invention by reference to the accompanying drawings.It should be noted that, when not conflicting, the feature in the embodiment of the application and embodiment can combine arbitrarily mutually.
As shown in Figure 1, a kind of virtual vulnerability mining system based on fuzz testing comprises a physical server and a Computer Service station, and described physical server and Computer Service station realize interconnecting by internet;
Described physical server is furnished with underlying virtualizing platform, underlying virtualizing platform is arranged one deck virtual machine, one deck virtual machine arranges two-layer virtual machine again; Described one deck virtual machine is furnished with fuzz testing monitoring module, two-layer virtual machine is furnished with fuzz testing module; Wherein, the running status of described fuzz testing monitoring module monitoring fuzz testing module, described fuzz testing module mainly completes the detection to virtual leak;
Described Computer Service station is furnished with abnormal collection module, data memory module and display module; Wherein, described abnormal collection module mainly collects abnormal information from fuzz testing monitoring module, is also responsible for the monitoring to physical server simultaneously; Described data memory module is mainly used in storing and analyzing abnormal information; Described display module is mainly used in showing various crash info.
Described fuzz testing module is the elementary cell of carrying out fuzz testing, and concrete Design and implementation has difference for different VMM.Mainly be divided into two classes: general fuzz testing module and the fuzz testing module for particular VM M.General fuzz testing module for all types of VMM, and for the fuzz testing of particular VM M for certain VMM or certain VMM assembly, such as CPU fuzz testing collection, for I/O fuzz testing collection, for online fuzzy test set etc.It mainly comprises finger daemon submodule and test submodule.
Described fuzz testing monitoring module is mainly monitored the object carrying out fuzz testing, and it mainly comprises virtual machine monitoring submodule, host monitoring submodule, information submodule and communicator module 4 function sub-modules.
Described abnormal collection module mainly collects abnormal information from each fuzz testing monitoring module, is also responsible for the monitoring to physical server simultaneously, mainly contains heartbeat submodule, data traffic module composition.
Described data memory module is mainly used in storing and analyzing abnormal information.Mainly comprise sub module stored and data analysis submodule
Described display module is mainly used in showing various crash info, as abnormal information classification displaying, according to condition search, report output etc.
Function and the working method of each submodule of described fuzz testing module are as follows:
Finger daemon submodule has two functions, and one is be responsible for sending information to fuzz testing monitoring module, and two is be responsible for producing stochastic inputs.Comprise in the information sent and cause abnormal input last time or the test after executing once test to complete message.Stochastic inputs is that these inputs will be supplied to test submodule and use according to all kinds of mistake input of virtual platform parts stochastic generation; It is all kinds of that mistake input comprises core instructions, I/O calls, system call, network data etc.
Test submodule is the test process generated separately for each assembly virtual, and the stochastic inputs of finger daemon submodule passes to test submodule by the mode shared between process, as CPU fuzz testing collection, for I/O fuzz testing collection, for online fuzzy test set etc.
Function and the working method of each submodule of described fuzz testing monitoring module are as follows:
Virtual machine monitoring submodule mainly monitors fuzz testing when carrying out, the situation that may occur of virtual machine, as large in resource occupation, collapse, deadlock etc.If virtual machine crashes crashes, this module can restart virtual machine.The fuzz testing module of restarting in rear virtual machine also can autoboot.
Host monitoring submodule is mainly monitored host hardware resource and is taken, as CPU, internal memory etc.When fuzz testing module makes host CPU usage too high and the duration is longer, or EMS memory occupation is large and the duration is long, and monitoring submodule determines whether exception according to threshold values.If be judged as abnormal, restart two-layer virtual machine, obtain and derive abnormal input information.
Information submodule is responsible for collecting all kinds of host information, as MUT module under test, Platform Type, version etc.These information will pass to abnormal collection module by communicator module.
Communicator module in charge intermediate communication, the information of upwards information submodule being collected, cause abnormal input information, other information send to abnormal collection module; Communicate with information submodule downwards, collect various information.
Function and the working method of each submodule of described abnormal collection module are as follows:
The operation of heartbeat submodule primary responsibility management and control physical server.Heartbeat submodule and physical server are set up one and are connected, if physical server occurs abnormal, such as one deck host goes wrong, server collapse is crashed, and heartbeat submodule can restart physical server by the remote control panel function (IPMI) of physical server.Heartbeat submodule comprises two links, and one is positioned on physical server, another be positioned at abnormal collection module is installed main frame on, two links must be positioned at different main frames and can UNICOM mutually, carry out heart-beat test at a certain time interval.
Data communication submodule mainly contains two functions, and one is the connection of monitoring fuzz testing monitoring module, collects abnormal information; Two is stored in data memory module by abnormal information.
Function and the working method of each submodule of described data memory module are as follows:
Sub module stored primary responsibility stores various information, as platform essential information, version, abnormal information with the form of non-mechanism; This submodule additionally provides read-write interface.
Data analysis submodule is mainly analyzed above-mentioned abnormal information, provides miscue or exception error file path etc. occurs.
A kind of above-mentioned method realizing virtual vulnerability mining based on the virtual vulnerability mining system of fuzz testing is utilized to comprise workflow, fuzz testing module work flow process, fuzz testing monitoring module workflow and abnormal collection module engineering process three part; Wherein,
Described workflow step is:
Step 1: start abnormal collection module;
Step 2: the IPMI interface remote that abnormal collection module is provided by server starts physical server;
Step 3: after physical server start, set up heartbeat with abnormal collection module and be connected, and automatically start underlying virtualizing platform, open one deck virtual machine;
Step 4: fuzz testing monitoring module starts automatically with after one deck virtual machine activation;
Step 5: fuzz testing is monitored and started (or restarting) two-layer virtual machine, the fuzz testing module start in two-layer virtual machine starts automatically, and the first thing after the unlatching of fuzz testing module sends input last time to fuzz testing monitoring module;
Step 6: fuzz testing module produces an input and saves, and then performs test; If two-layer virtual machine does not collapse, fuzz testing module sends a test to fuzz testing monitoring module and completes message, if cause exception, fuzz testing monitoring module meeting autoboot two-layer virtual machine, jump to step 5, otherwise proceed test next time after waiting for 12 seconds, rebound step 6;
Step 7: if one deck virtual machine crashes, underlying virtualizing platform autoboot two-layer virtual machine, skips to step 4;
Step 8: if physical server collapse, abnormal collection module can monitor, and then utilizes remote control panel autoboot server, rebound step 1;
Step 9: abnormal collection module is by all kinds of collection information stored in data memory module, and data memory module, to collection data analysis, is sent to display module;
Step 10: display module shows exception error information, platform information etc.;
Described fuzz testing module work flow process is:
Step 1: finger daemon submodule starts with the start of two-layer virtual machine, and first last fuzz testing being performed content after startup sends to fuzz testing monitoring module, and this input is kept in a local security file;
Step 2: for different test suite, tests submodule initialization accordingly;
Step 3: produce a stochastic inputs for test suite in step 2, and be saved to local security file;
Step 4: a new generation process, performs test submodule;
Step 5: send test to fuzz testing monitoring module and complete message;
Step 6: wait for certain hour, fuzz testing monitoring module monitoring host and virtual machine state, if there is exception, fuzz testing monitoring module directly can restart virtual machine, then skips to step 1, otherwise skips to step 3 continuation execution;
Described fuzz testing monitoring module workflow is:
Step 1: initialization information collects submodule, according to configuration file, collects corresponding tested virtualisation component information, as VMM type, version, host dummy machine system version etc.; That abnormal collection module is together issued in these information and abnormal input when generation is abnormal;
Step 2: start two-layer virtual machine by Virtual Machine Manager interface;
Step 3: set up UDP and monitor, receiving the message sent from fuzz testing module, if certain hour is for receiving message, then restarting two-layer virtual machine; Extremely input message if received, be then sent to abnormal collection module together with the information of abnormal input and information submodule being collected; If receive test to complete message, then check virtual machine and host state by virtual machine monitoring submodule, host monitoring submodule, if occur abnormal, then restart two-layer virtual machine;
Described abnormal collection module workflow is:
Step 1: start heartbeat submodule, heartbeat submodule sets up the message of UDP monitoring from physical server end, and heartbeat occurs once, if exceed certain hour section with certain hour section, then think that physical server is abnormal, then restart physical server by IPMI interface;
Step 2: physical server heartbeat service is opened, and to heartbeat submodule generation heartbeat packet;
Step 3: set up UDP monitoring from the connection of each fuzz testing monitoring module, if there is unexpected message to send over, according to the type of abnormal information, write in data memory module by data communication submodule.The all or part of step that one of ordinary skill in the art will appreciate that in said method is carried out instruction related hardware by program and is completed, and described program can be stored in computer-readable recording medium, as ROM (read-only memory), disk or CD etc.Alternatively, all or part of step of above-described embodiment also can use one or more integrated circuit to realize.Correspondingly, each module/unit in above-described embodiment can adopt the form of hardware to realize, and the form of software function module also can be adopted to realize.The application is not restricted to the combination of the hardware and software of any particular form.
The above, be only preferred embodiments of the present invention, be not intended to limit protection scope of the present invention.Within the spirit and principles in the present invention all, any amendment made, equivalent replacement, improvement etc., all should be included within protection scope of the present invention.
Claims (6)
1. based on a virtual vulnerability mining system for fuzz testing, it is characterized in that: described vulnerability mining system comprises a physical server and a Computer Service station, described physical server and Computer Service station realize interconnecting by internet;
Described physical server is furnished with underlying virtualizing platform, underlying virtualizing platform is arranged one deck virtual machine, one deck virtual machine arranges two-layer virtual machine again; Described one deck virtual machine is furnished with fuzz testing monitoring module, two-layer virtual machine is furnished with fuzz testing module; Wherein, the running status of described fuzz testing monitoring module monitoring fuzz testing module, described fuzz testing module mainly completes the detection to virtual leak;
Described Computer Service station is furnished with abnormal collection module, data memory module and display module; Wherein, described abnormal collection module mainly collects abnormal information from fuzz testing monitoring module, is also responsible for the monitoring to physical server simultaneously; Described data memory module is mainly used in storing and analyzing abnormal information; Described display module is mainly used in showing various crash info.
2. a kind of virtual vulnerability mining system based on fuzz testing as claimed in claim 1, it is characterized in that: described fuzz testing monitoring module is mainly monitored the object carrying out fuzz testing, it mainly comprises virtual machine monitoring submodule, host monitoring submodule, information submodule and communicator module 4 function sub-modules; Wherein,
Described virtual machine monitoring submodule mainly monitors the unusual condition that when fuzz testing carries out, virtual machine may occur; Described host monitoring submodule mainly monitors one deck virtual machine hardware occupation condition; Described information submodule is responsible for the information of collecting one deck virtual machine and two-layer virtual machine, and all kinds of host informations of described collection will pass to abnormal collection module by communicator module; Described communicator module in charge intermediate communication, upwards by information submodule collect information, cause the status information of abnormal input information and one deck virtual machine and two-layer virtual machine to send to abnormal collection module; Communicate with information submodule downwards and collect information.
3. a kind of virtual vulnerability mining system based on fuzz testing as claimed in claim 1, is characterized in that: described fuzz testing module comprises finger daemon submodule and test submodule; Wherein said finger daemon submodule is responsible for sending information to fuzz testing monitoring module and being responsible for producing stochastic inputs; Described finger daemon submodule is responsible for comprising in fuzz testing monitoring module transmission information and is caused abnormal input last time or the test after executing once test to complete message, described stochastic inputs is that described mistake input will be supplied to test submodule and use according to all kinds of mistake input of virtual platform parts stochastic generation; Described test submodule is the test process generated separately for each assembly virtual, and the stochastic inputs of described finger daemon submodule passes to test submodule by the mode shared between process.
4. a kind of virtual vulnerability mining system based on fuzz testing as claimed in claim 1, is characterized in that: described abnormal collection module comprises data communication submodule and heartbeat submodule; Wherein, the operation of described heartbeat submodule primary responsibility management and control physical server, described heartbeat submodule comprises two links, one is positioned on physical server, another be positioned at abnormal collection module is installed computer workstation on, and two links are arranged in different computer workstations and energy UNICOM mutually, carry out heart-beat test at a certain time interval; Described data traffic module in charge is monitored the connection of fuzz testing monitoring module and is collected abnormal information and be responsible for abnormal information stored in data memory module.
5. a kind of virtual vulnerability mining system based on fuzz testing as claimed in claim 1, is characterized in that: described data storage module comprises sub module stored and data analysis submodule; Wherein, described sub module stored is responsible for storing various information with the form of non-mechanism and being responsible for providing read-write interface; Described data analysis submodule is responsible for analyzing and provide miscue or prompting exception error file path to abnormal information.
6. utilize a kind of method realizing vulnerability mining based on the virtual vulnerability mining system of fuzz testing as claimed in claim 1 to comprise workflow, fuzz testing module work flow process, fuzz testing monitoring module workflow and abnormal collection module engineering process three part; Wherein,
Described workflow step is:
Step 1: start abnormal collection module;
Step 2: the IPMI interface remote that abnormal collection module is provided by server starts physical server;
Step 3: after physical server start, set up heartbeat with abnormal collection module and be connected, and automatically start underlying virtualizing platform, open one deck virtual machine;
Step 4: fuzz testing monitoring module starts automatically with after one deck virtual machine activation;
Step 5: fuzz testing is monitored and started or restart two-layer virtual machine, the fuzz testing module start in two-layer virtual machine starts automatically, and the first thing after the unlatching of fuzz testing module sends input last time to fuzz testing monitoring module;
Step 6: fuzz testing module produces an input and saves, and then performs test; If two-layer virtual machine does not collapse, fuzz testing module sends a test to fuzz testing monitoring module and completes message, if cause exception, fuzz testing monitoring module meeting autoboot two-layer virtual machine, jump to step 5, otherwise proceed test next time after waiting for 12 seconds, rebound step 6;
Step 7: if one deck virtual machine crashes, underlying virtualizing platform autoboot two-layer virtual machine, skips to step 4;
Step 8: if physical server collapse, abnormal collection module can monitor, and then utilizes remote control panel autoboot server, rebound step 1;
Step 9: abnormal collection module is by all kinds of collection information stored in data memory module, and data memory module, to collection data analysis, is sent to display module;
Step 10: display module shows exception error information and platform information;
Described fuzz testing module work flow process is:
Step 1: finger daemon submodule starts with the start of two-layer virtual machine, and first last fuzz testing being performed content after startup sends to fuzz testing monitoring module, and this input is kept in a local security file;
Step 2: for different test suite, tests submodule initialization accordingly;
Step 3: produce a stochastic inputs for test suite in step 2, and be saved to local security file;
Step 4: a new generation process, performs test submodule;
Step 5: send test to fuzz testing monitoring module and complete message;
Step 6: wait for certain hour, fuzz testing monitoring module monitoring host and virtual machine state, if there is exception, fuzz testing monitoring module directly can restart virtual machine, then skips to step 1, otherwise skips to step 3 continuation execution;
Described fuzz testing monitoring module workflow is:
Step 1: initialization information collects submodule, according to configuration file, collects corresponding tested virtualisation component information; That abnormal collection module is together issued in corresponding tested virtualisation component information and the abnormal input of described collection when generation is abnormal;
Step 2: start two-layer virtual machine by Virtual Machine Manager interface;
Step 3: set up UDP and monitor, receiving the message sent from fuzz testing module, if certain hour is for receiving message, then restarting two-layer virtual machine; Extremely input message if received, be then sent to abnormal collection module together with the information of abnormal input and information submodule being collected; If receive test to complete message, then check virtual machine and host state by virtual machine monitoring submodule, host monitoring submodule, if occur abnormal, then restart two-layer virtual machine;
Described abnormal collection module workflow is:
Step 1: start heartbeat submodule, heartbeat submodule sets up the message of UDP monitoring from physical server end, and heartbeat occurs once, if exceed certain hour section with certain hour section, then think that physical server is abnormal, then restart physical server by IPMI interface;
Step 2: physical server heartbeat service is opened, and to heartbeat submodule generation heartbeat packet;
Step 3: set up UDP monitoring from the connection of each fuzz testing monitoring module, if there is unexpected message to send over, according to the type of abnormal information, write in data memory module by data communication submodule.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510626457.8A CN105160259B (en) | 2015-09-28 | 2015-09-28 | A kind of virtualization vulnerability mining system and method based on fuzz testing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510626457.8A CN105160259B (en) | 2015-09-28 | 2015-09-28 | A kind of virtualization vulnerability mining system and method based on fuzz testing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105160259A true CN105160259A (en) | 2015-12-16 |
| CN105160259B CN105160259B (en) | 2018-01-23 |
Family
ID=54801111
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510626457.8A Active CN105160259B (en) | 2015-09-28 | 2015-09-28 | A kind of virtualization vulnerability mining system and method based on fuzz testing |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105160259B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112327732A (en) * | 2020-10-22 | 2021-02-05 | 深圳达实智能股份有限公司 | Smart building interior micro-edge service control method and system and electronic equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080244747A1 (en) * | 2007-03-30 | 2008-10-02 | Paul Gleichauf | Network context triggers for activating virtualized computer applications |
| CN101986280A (en) * | 2010-11-29 | 2011-03-16 | 浙江大学 | Automatic testing platform for virtual computing system |
| CN102447723A (en) * | 2010-10-12 | 2012-05-09 | 运软网络科技(上海)有限公司 | Client-side virtualization framework |
| CN102457439A (en) * | 2011-12-07 | 2012-05-16 | 中标软件有限公司 | Virtual switching system and method of cloud computing system |
-
2015
- 2015-09-28 CN CN201510626457.8A patent/CN105160259B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080244747A1 (en) * | 2007-03-30 | 2008-10-02 | Paul Gleichauf | Network context triggers for activating virtualized computer applications |
| CN102447723A (en) * | 2010-10-12 | 2012-05-09 | 运软网络科技(上海)有限公司 | Client-side virtualization framework |
| CN101986280A (en) * | 2010-11-29 | 2011-03-16 | 浙江大学 | Automatic testing platform for virtual computing system |
| CN102457439A (en) * | 2011-12-07 | 2012-05-16 | 中标软件有限公司 | Virtual switching system and method of cloud computing system |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112327732A (en) * | 2020-10-22 | 2021-02-05 | 深圳达实智能股份有限公司 | Smart building interior micro-edge service control method and system and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105160259B (en) | 2018-01-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103235756B (en) | A kind of emulation test method of embedded system subregion application software | |
| US9483383B2 (en) | Injecting faults at select execution points of distributed applications | |
| US8850172B2 (en) | Analyzing performance of computing devices in usage scenarios | |
| US8738968B2 (en) | Configuration based service availability analysis of AMF managed systems | |
| Huang et al. | Towards architecture-based management of platforms in the cloud | |
| CN102571498B (en) | Fault injection control method and device | |
| CN102521105B (en) | Output method of power on self test information, virtual machine manager and processor | |
| CN112181833A (en) | Intelligent fuzzy test method, device and system | |
| Riganelli et al. | Data loss detector: automatically revealing data loss bugs in Android apps | |
| CN113590454A (en) | Test method, test device, computer equipment and storage medium | |
| Chen et al. | Using runtime paths for macroanalysis | |
| EP2713277B1 (en) | Latent defect identification | |
| US11750471B2 (en) | Method and apparatus for determining resource configuration of cloud service system | |
| CN110990289B (en) | Method and device for automatically submitting bug, electronic equipment and storage medium | |
| CN105160259A (en) | Fuzzy testing based virtualized vulnerability mining system and method | |
| Cotroneo et al. | Dependability certification guidelines for NFVIS through fault injection | |
| CN109901831A (en) | The multi-platform compatibility operation method and compatibility operation device of software | |
| Seo et al. | Automating embedded software testing on an emulated target board | |
| Zhou et al. | Delta execution for software reliability | |
| CN112035295A (en) | Virtual machine crash event processing method, system, terminal and storage medium | |
| Xu et al. | Modeling and analysing operation processes for dependability | |
| Loveland et al. | Testing z/OS: The premier operating system for IBM's zSeries server | |
| KR101567879B1 (en) | Virtual machine state analyzing system | |
| US11726854B2 (en) | Host malfunction detection for CI/CD systems | |
| Cronqvist | Troubleshooting a large Erlang system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |