I 1111111111111111 1111111111 11111 111111111111111 IIIII IIIII IIIIII IIII IIII IIII
`US010027693B2
`
`c12) United States Patent
`Jiang
`
`(IO) Patent No.: US 10,027,693 B2
`(45) Date of Patent:
`Jul. 17, 2018
`
`(54) METHOD, DEVICE AND SYSTEM FOR
`ALERTING AGAINST UNKNOWN
`MALICIOUS CODES WITHIN A NETWORK
`ENVIRONMENT
`
`(71) Applicant: Huawei Digital Technologies (Cheng
`Du) Co., Limited, Chengdu (CN)
`
`(72)
`
`Inventor: Wu Jiang, Beijing (CN)
`
`(73) Assignee: Huawei Digital Technologies (Cheng
`Du) Co., Limited, Chengdu (CN)
`
`(58) Field of Classification Search
`CPC ............................. G06F 21/55; H04L 63/1408
`(Continued)
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`7,007,302 Bl
`8,201,247 Bl
`
`2/2006 Jagger et al.
`6/2012 Chen et al.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`
`7/2007
`1997017 A
`10/2007
`101052934 A
`(Continued)
`
`OTHER PUBLICATIONS
`
`!51 Office Action in corresponding U.S. Appl. No. 13/481,273 ( dated
`Mar. 28, 2013).
`
`(Continued)
`
`Primary Examiner - Bryan Wright
`(74) Attorney, Agent, or Firm - Leydig, Voit & Mayer,
`Ltd.
`
`ABSTRACT
`(57)
`A method, a device, and a system for alerting against
`unknown malicious codes includes judging whether any
`suspicious code exists in the packet, recording a source path
`of the suspicious code and sending alert information that
`carries the source path to a monitoring device. The embodi(cid:173)
`ments of the present disclosure report the source paths of
`suspicious codes proactively at the earliest possible time,
`which lays a foundation for shortening the time required for
`overcoming virus threats, and avoids the trouble of installing
`software on the terminal.
`
`9 Claims, 4 Drawing Sheets
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 266 days.
`
`CN
`CN
`
`(21) Appl. No.: 15/081,018
`
`(22) Filed:
`
`Mar. 25, 2016
`
`(65)
`
`Prior Publication Data
`
`US 2016/0212160 Al
`
`Jul. 21, 2016
`
`Related U.S. Application Data
`
`(63) Continuation-in-part of application No. 13/481,273,
`filed on May 25, 2012, now Pat. No. 9,674,206,
`(Continued)
`
`(30)
`
`Foreign Application Priority Data
`
`Nov. 26, 2009
`
`(CN) .......................... 2009 1 0247172
`
`(51)
`
`Int. Cl.
`H04L 29106
`G06F 21/55
`(52) U.S. Cl.
`CPC ...... H04L 63/1416 (2013.01); H04L 63/1425
`(2013.01); G06F 21/55 (2013.01); H04L
`63/1408 (2013.01); H04L 2463/146 (2013.01)
`
`(2006.01)
`(2013.01)
`
`receive, by a netv-.rork device, a request for obtaining a file
`from a sent by a tem1inal for obtaining a Jile from a
`net\vork entity and a data stream carrying the file
`
`105
`
`record, by the network device, a source path carried in the request,
`wherein the network entity providing the file on the source path
`
`judge, by the network device, whether the file is an executable
`file according to the request or the data stream carried the file
`
`send, by the net\vork device, first akrt infonnation that t:arrie:-i the
`source path to a monitoring device, if the network device judges the
`lile is the executable Jile
`
`204
`
`receiving, by the network device, second alarm
`information sent by the monitoring device
`
`110
`
`128
`
`130
`
`216
`
`225
`
`intercepting, by the network device, suspicious
`codes that are malicious according to
`malidousness of the suspiduus cu1.h:s
`
`intercepting, by the network device, the
`suspicious codes that are malicious and the
`packets in the Botnet
`
`Juniper Ex. 1001-p. 1
`Juniper v Huawei
`
`

`

`US 10,027,693 B2
`Page 2
`
`Related U.S. Application Data
`
`which is a continuation of application No. PCT/
`CN2010/078951, filed on Nov. 22, 2010.
`( 58) Field of Classification Search
`USPC . ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... .. 726/23
`See application file for complete search history.
`
`2012/0054869 Al*
`
`2012/0151033 Al*
`
`2012/0233691 Al
`2014/0013434 Al*
`
`3/2012 Yen ................... H04L 29/12066
`726/24
`6/2012 Baliga ................. H04L 63/1425
`709/224
`
`9/2012 Jiang
`1/2014 Ranum ................. H04L 63/145
`726/24
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`8,826,438 B2 *
`
`8,555,388 Bl * 10/2013 Wang .................. H04L 63/1416
`709/245
`8,578,493 Bl * 11/2013 Cowan .................. G06F 21/554
`709/224
`9/2014 Perdisci .................. G06F 21/56
`709/236
`9,215,239 Bl* 12/2015 Wang .................. H04L 63/1408
`1/2003 Gupta et al.
`2003/0009699 Al
`2004/0148281 Al
`7/2004 Bates et al.
`2006/0021040 Al
`1/2006 Boulanger et al.
`2008/0162715 Al
`7/2008 Wary
`2008/0313738 Al
`12/2008 Enderby
`2009/0113548 Al*
`4/2009 Gray ..................... G06F 21/552
`726/24
`
`FOREIGN PATENT DOCUMENTS
`
`CN
`CN
`CN
`CN
`CN
`EP
`KR
`
`101212753 A
`101242416 A
`101286850 A
`101587521 A
`101714931 A
`1461704 Bl
`20090078691 A
`
`7/2008
`8/2008
`10/2008
`11/2009
`5/2010
`8/2014
`7/2009
`
`OTHER PUBLICATIONS
`
`2nd Office Action in corresponding U.S. Appl. No. 13/481,273
`(dated Sep. 26, 2013).
`
`* cited by examiner
`
`Juniper Ex. 1001-p. 2
`Juniper v Huawei
`
`

`

`U.S. Patent
`
`Jul. 17, 2018
`
`Sheet 1 of 4
`
`US 10,027,693 B2
`
`101
`
`102
`
`103
`
`104
`
`receive, by a network device, a request for
`obtaining a file from a server sent by a client
`
`record, by the network device, a source path
`according to which the server downloads the file
`
`detect, by the network device, whether the file is
`an executable file
`
`send, by the network device, alert information that
`carries the source path to a monitoring device, if the
`network device judges the file is the executable file
`
`FIG. 1
`
`Juniper Ex. 1001-p. 3
`Juniper v Huawei
`
`

`

`U.S. Patent
`
`Jul. 17, 2018
`
`Sheet 2 of 4
`
`US 10,027,693 B2
`
`receive, by a network device, a request for obtaining a file l,,-----/ 105
`from a sent by a terminal for obtaining a file from a
`network entity and a data stream carrying the file
`
`+
`
`record, by the network device, a source path carried in the request,
`wherein the network entity providing the file on the source path
`
`+
`
`judge, by the network device, whether the file is an executable
`file according to the request or the data stream carried the file
`
`-
`
`110
`
`,-----/ 128
`
`'
`send, by the network device, first alert information that carries the l.-------/ 130
`
`source path to a monitoring device, if the network device judges the
`file is the executable file
`
`,-----/204
`
`+
`
`-
`
`receiving, by the network device, second alarm
`information sent by the monitoring device
`
`,-----/ 216
`
`intercepting, by the network device, suspicious
`codes that are malicious according to
`maliciousness of the suspicious codes
`
`,,
`/
`intercepting, by the network device, the
`suspicious codes that are malicious and the
`packets in the Botnet
`
`225
`
`FIG. 2
`
`Juniper Ex. 1001-p. 4
`Juniper v Huawei
`
`

`

`U.S. Patent
`
`Jul. 17, 2018
`
`Sheet 3 of 4
`
`US 10,027,693 B2
`
`306
`
`second intercepting
`module
`
`305
`
`301
`
`302
`
`303
`
`304
`
`first intercepting
`module
`
`receiving module
`
`recording module
`
`detecting module
`
`sending module
`
`FIG. 3
`
`Juniper Ex. 1001-p. 5
`Juniper v Huawei
`
`

`

`U.S. Patent
`
`Jul. 17, 2018
`
`Sheet 4 of 4
`
`US 10,027,693 B2
`
`401
`
`402
`
`403
`
`404
`
`receiving module
`
`downloading module
`
`detecting module
`
`sending module
`
`FIG. 4
`
`501
`
`512
`
`Network device
`
`Monitoring device
`
`FIG. 5
`
`Juniper Ex. 1001-p. 6
`Juniper v Huawei
`
`

`

`US 10,027,693 B2
`
`1
`METHOD, DEVICE AND SYSTEM FOR
`ALERTING AGAINST UNKNOWN
`MALICIOUS CODES WITHIN A NETWORK
`ENVIRONMENT
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`5
`
`This application is a continuation-in-part application of a
`U.S. patent application Ser. No. 13/481,273, filed on May 10
`25, 2012, which is a continuation of International Patent
`Application No. PCT/CN2010/078951, filed on Nov. 22,
`2010, which claims priority to Chinese Patent Application
`No. 200910247172.8, filed on Nov. 26, 2009. The afore- 15
`mentioned patent applications are hereby incorporated by
`reference in their entireties.
`
`TECHNICAL FIELD
`
`The present disclosure relates to network security tech(cid:173)
`nologies, and in particular, to a method, a device, and a
`system for alerting against unknown malicious codes.
`
`BACKGROUND
`
`2
`rece1vmg, by a network device, a request sent by a
`terminal for obtaining a file from a network entity and a data
`stream carrying the file;
`recording, by the network device, a source path carried in
`the request, wherein the network entity providing the file on
`the source path;
`judging, by the network device, whether the file is an
`executable file according to the request or the data stream
`carried the file; and
`sending, by the network device, first alert information that
`carries the source path to a monitoring device, if the network
`device judges the file is the executable file.
`An embodiment of the present disclosure provides a
`network device, including:
`a receiving module, configured to receive a request sent
`by a terminal for obtaining a file from a network entity and
`receive a data stream carrying the file;
`a recording module, configured to record a source path
`carried in the request, wherein the network entity providing
`20 the file on the source path;
`a detecting module, configured to judge whether the file
`is an executable file according to the request or the data
`stream carried the file; and
`a sending module, configured to send first alert informa-
`25 tion that carries the source path to a monitoring device, if the
`network device judges the file is the executable file.
`An embodiment of the present disclosure provides a
`system for alerting against unknown malicious codes. The
`system includes a network device according to above and a
`30 monitoring device, where the monitoring device is configure
`to receive first alert information that carries a source path
`sent from the network device; download an executable file
`according to the source path; detect the executable file to
`confirm maliciousness of the executable file; send second
`35 alarm information to the network device, wherein the second
`alarm information comprises maliciousness of the execut(cid:173)
`able file, or comprises both the maliciousness of the execut(cid:173)
`able and Botnet topology information.
`Therefore, the method, the device, and the system for
`40 alerting against unknown malicious codes in the embodi(cid:173)
`ments of the present disclosure report source path of numer(cid:173)
`ous suspicious codes proactively at the earliest possible
`time, enable the vendor to obtain the source path of mali(cid:173)
`cious code samples shortly after the malicious codes occur,
`45 ensure comprehensiveness of the alert information source,
`lay a foundation for shortening the time required for over(cid:173)
`coming virus threats, and avoid the trouble of installing
`software on the terminal.
`
`With popularization of the Internet, higher network secu(cid:173)
`rity is required. Loopholes are frequently used for launching
`attacks. The time from discovery to use of a security
`loophole is now shortened from a few months to a few days.
`Once a loophole is discovered, it is used for launching
`attacks shortly. For such attacks, it usually takes a long time
`for the vendor to obtain a sample of malicious codes, and it
`is slower to release the corresponding patches. Therefore,
`such attacks tend to cause huge damages. MS Blast was used
`for launching attacks hardly in less than 25 days after it was
`discovered, and Nachi (a variant of MS Blast) was used for
`launching attacks in less than one week after it was discov(cid:173)
`ered. If the malicious codes are discovered early, the attacks
`can be prevented in time, and the loss caused by malicious
`codes will be reduced.
`In the conventional art, network devices are unable to
`report suspicious codes. After the malicious code attack is
`launched, it takes a long time for the vendor to obtain the
`malicious code sample. Antivirus software analyzes files
`downloaded to the computer and reports the analysis result
`to the monitoring center. However, the computer may still be
`attacked by downloaded malicious codes if the downloaded
`data is not treated properly, which brings a heavy burden
`onto the computer. Antivirus software has to be installed on 50
`the computer, which is troublesome to the user. For such
`reasons, some users refuse to install antivirus software on
`network devices so that such devices are more vulnerable to
`propagation of malicious codes.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`SUMMARY
`
`An embodiment of the present disclosure provides a
`method, a device, and a system for alerting against unknown
`malicious codes, so as to report source path of numerous 60
`suspicious codes proactively at the earliest possible time, lay
`a foundation for shortening the time required for overcom(cid:173)
`ing virus threats, and avoid the trouble of installing software
`on the terminal.
`An embodiment of the present disclosure provides a 65
`method for alerting against unknown malicious codes,
`including:
`
`To make the technical solution under the present disclo(cid:173)
`sure or in the conventional art clearer, the following outlines
`the accompanying drawings involved in the description of
`55 the embodiments of the present disclosure or the conven(cid:173)
`tional art. Apparently, the accompanying drawings outlined
`below are illustrative rather than exhaustive, and persons of
`ordinary skill in the art can derive other drawings from them
`without any creative effort.
`FIG. 1 is a schematic diagram of a method for alerting
`against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure;
`FIG. 2 is a schematic diagram of a method for alerting
`against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure;
`FIG. 3 is a schematic diagram of a network device
`according to an embodiment of the present disclosure; and
`
`Juniper Ex. 1001-p. 7
`Juniper v Huawei
`
`

`

`US 10,027,693 B2
`
`3
`FIG. 4 is a schematic diagram of a monitoring device
`according to an embodiment of the present disclosure; and
`FIG. 5 is a schematic diagram of a system for alerting
`against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure.
`
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`
`5
`
`4
`detecting, by the network device, whether a string which
`indicating the name of the executable file exists in the
`request; and/or
`detecting, by the network device, whether a file header of
`the executable file exists in the data which transmitted by the
`data stream returned by the server.
`Specifically, at the time of detecting whether a string
`which indicating the name of the executable file exists in the
`request, if a string like get * .exe is detected in the packet, it
`10 indicates that an executable file is being transmitted, in
`which * .exe is a suspicious code, and * represents a string
`of a random length. The executable file may leak informa(cid:173)
`tion of the terminal user, damage the terminal system, or
`15 even let the terminal be controlled by the attacker. Or, if a
`packet includes strings like get * .dll or get * .ocx, it indicates
`that an executable file, that is a string of malicious codes is
`being transmitted, which may leak information of the ter(cid:173)
`minal user, damage the terminal system, or even let the
`20 terminal be controlled by the attacker. Such codes need to be
`reported.
`At the time of detecting whether a file header of the
`executable file exists in the file returned by the server, if a
`PE (portable executable) file header characteristic code
`25 "MZ" is detected (MZ is expressed by American Standard
`Code for Information Interchange (ASCII) codes), the PE
`file may leak information of the terminal user, damage the
`terminal system, or even let the terminal be controlled by the
`attacker when the PE file is executed. Therefore, the PE file
`30 is a string of suspicious codes.
`When the two detection methods above are combined, if
`get * .jpg is detected and a PE file header characteristic code
`"MZ" is detected (MZ is expressed by ASCII codes) in the
`corresponding data, the PE file is a string of suspicious
`35 codes, because the user attempts to download a picture but
`an executable file is returned. The spoofing indicates that the
`PE file is probably is a string of malicious codes.
`If the suspicious code is detected by checking whether the
`name of the executable file is included in the data stream, the
`40 source path generally appears in the URL after get. If both
`of the detection methods are applied in detecting the execut(cid:173)
`able file, the source address generally appears in the URL
`after get,
`If the network device judges the file is the executable file,
`the network device generates first alert information that
`carries the source path and sends the first alert information
`to the monitoring device. After the first alert information is
`sent, the network device receives second alarm information
`returned by the monitoring device.
`The method for alerting against unknown malicious codes
`in this embodiment reports source path of numerous suspi(cid:173)
`cious codes proactively at the earliest possible time, enables
`the vendor to obtain the source path of malicious code
`samples shortly after the malicious codes occur, ensures
`55 comprehensiveness of the alert information source, lays a
`foundation for shortening the time required for overcoming
`virus threats, and avoids the trouble of installing software on
`the terminal.
`FIG. 2 is a schematic diagram of a method for alerting
`60 against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure. The method in this embodi(cid:173)
`ment includes the following steps:
`Step 105: receiving, by a network device, a request for
`obtaining a file from a sent by a terminal for obtaining a file
`65 from a network entity;
`receiving, by a network device, a data stream carrying the
`file;
`
`The following detailed description is given in conjunction
`with the accompanying drawings to provide a thorough
`understanding of the present disclosure. Evidently, the draw(cid:173)
`ings and the detailed description are merely representative of
`particular embodiments of the present disclosure rather than
`all embodiments. All other embodiments, which can be
`derived by those skilled in the art from the embodiments
`given herein without any creative effort, shall fall within the
`protection scope of the present disclosure.
`The following describes the technical solution of the
`present disclosure in detail.
`FIG. 1 is a schematic diagram of a method for alerting
`against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure. The method in this embodi(cid:173)
`ment includes the following steps:
`Step 101: receive, by a network device, a request sent by
`a terminal for obtaining a file from a network entity and a
`data stream carrying the file;
`Step 102: record, by the network device, a source path
`carried in the request, wherein the network entity providing
`the file on the source path;
`Step 103: judge, by the network device, whether the file
`is an executable file according to the request or the data
`stream carried the file; and
`Step 104: send, by the network device, first alert infor(cid:173)
`mation that carries the source path to a monitoring device,
`if the network device judges the file is the executable file.
`The entity for performing the steps of this embodiment is
`a network device. The source path is sent to the monitoring
`device so that the monitoring device could download the file
`according to the source path, and detect the executable file
`to confirm maliciousness of the executable file in time.
`In this embodiment, whether the file is an executable file
`is detected. When the file is an executable file, then it is 45
`regards as suspicious codes. For example, the detection
`method is to detect whether a string which indicating the
`name of the executable file exists in the request, and/or
`whether a file header of the executable file exists in the data
`returned by the server.
`In this embodiment, the terminal sends the request for
`obtaining the file from the network entity, especially, the
`network entity is server providing the file on the source path,
`for example, the network entity is a Web server of a FTP
`(File Transfer Protocol) server.
`The request may be an HTTP get request or an FTP
`request, wherein the request contains the source path accord(cid:173)
`ing to which the server providing the file.
`The network device may be a network gateway device
`between the terminal and the network entity. The network
`device will receive the request. After the network device
`receiving the request, the network device records a source
`path according to which the server providing the file. The
`source path generally appears in the URL after get.
`The network device, detects whether the file is an execut(cid:173)
`able file. The detecting, by the network device, whether the
`file is the executable file comprises:
`
`50
`
`Juniper Ex. 1001-p. 8
`Juniper v Huawei
`
`

`

`US 10,027,693 B2
`
`5
`Step 110: recording, by the network device, a source path
`carried in the request, wherein the network entity providing
`the file on the source path;
`Step 128: judging, by the network device, whether the file
`is an executable file according to the request or the data 5
`stream carried the file;
`Step 130: sending, by the network device, first alert
`information that carries the source path to a monitoring
`device, if the network device judges the file is the executable
`file;
`Step 204: receiving, by the network device, second alarm
`information sent by the monitoring device. The second
`alarm information includes maliciousness of the suspicious
`code, or includes both the maliciousness of the suspicious 15
`code and the Botnet topology information.
`This embodiment differs from the previous embodiment
`in that: the network device receives second alarm informa(cid:173)
`tion returned by the monitoring device after sending first
`alert information. The second alarm information includes 20
`maliciousness of the suspicious code against which the alert
`is raised, or includes both the maliciousness of the suspi(cid:173)
`cious code and the Botnet topology information.
`The monitoring device may identify maliciousness of the
`suspicious code through characteristics detection, sandbox 25
`test, or both.
`If the monitoring device uses characteristics detection to
`calculate possibility of maliciousness, the monitoring device
`compares the suspicious code with a more detailed reposi(cid:173)
`tory of malicious code characteristics. If the suspicious code
`matches any characteristics in the repository of malicious
`code characteristics, the monitoring device can calculate the
`probability of attacks launched by the malicious code
`according to the matching extent, and identify possibility of
`such attacks, namely, maliciousness possibility. For
`example, if the suspicious code matches a string of suspi(cid:173)
`cious code characteristics regarded as having an 80% prob(cid:173)
`ability of launching attacks in the characteristics repository,
`the suspicious code is also regarded as having an 80%
`probability of launching attacks. If this probability exceeds
`the alarm threshold, the suspicious code is possibly mali(cid:173)
`c10us.
`If the monitoring device uses a sandbox to calculate the
`maliciousness possibility, the monitoring device runs the
`suspicious code in the sandbox automatically, records the
`execution result and the running status, and calculates the
`maliciousness possibility according to the record. The sand(cid:173)
`box is a professional virtual environment. The program that
`runs in the sandbox is redirected into the sandbox when 50
`modifying a registry or a file. In this way, if the program is
`malicious, no impact is caused outside the sandbox. Even if
`an attack is launched in the sandbox, the attack impact is
`cancelled by restarting the sandbox. For example, the moni-
`taring device detects that a malicious event is triggered in
`the process of running a suspicious code, and the probability
`of launching attacks from the event is 40%. Therefore, the
`maliciousness possibility of the suspicious code is 40%. If
`this probability exceeds the alarm threshold, the suspicious 60
`code is possibly malicious.
`If the suspicious code that the monitoring device down(cid:173)
`loads according to the first alert information is determined as
`malicious, the monitoring device may retrieve the Botnet
`topology information in the malicious code, and generates 65
`and sends second alarm information that carries the Botnet
`topology information.
`
`6
`The Botnet topology information in the foregoing mali(cid:173)
`cious code includes Bot hosts as well as the Internet Protocol
`(IP) address, port, or Uniform Resource Locator (URL) that
`controls the hosts.
`After the monitoring device sends the second alarm
`information that carries the Botnet topology information, the
`network device receives the alarm information sent by the
`monitoring device. The second alarm information includes
`maliciousness of the suspicious code, or includes both the
`maliciousness of the suspicious code and the Botnet topol(cid:173)
`ogy information.
`The method in this embodiment may further include the
`following steps:
`Step 216: intercepting, by the network device, suspicious
`codes that are malicious according to maliciousness of the
`suspicious codes; or
`Step 225: intercepting, by the network device, the suspi(cid:173)
`cious codes that are malicious and the packets in the Botnet
`corresponding to the Botnet topology information according
`to maliciousness of the suspicious codes and the Botnet
`topology information.
`After receiving the second alarm information, the network
`device intercepts the corresponding suspicious codes and the
`packets in the Botnet.
`The method for alerting against unknown malicious codes
`in this embodiment reports source path of numerous suspi(cid:173)
`cious codes proactively at the earliest possible time, ensures
`comprehensiveness of the alert information sources, lays a
`30 foundation for shortening the time required for overcoming
`virus threats, and avoids the trouble of installing software on
`the terminal. Moreover, because the network device sends
`the source path of the suspicious codes rather than the
`35 suspicious codes themselves, the occupancy of user band(cid:173)
`width is reduced; the monitoring device analyzes the sus(cid:173)
`picious codes and sends alarms to the network device so that
`the network device can intercept malicious codes; the moni(cid:173)
`toring device retrieves the Botnet topology information and
`40 sends Botnet alarms to the network device, and therefore,
`the network device intercepts the packets in the Botnet,
`which reduces possibility of the host being attacked.
`FIG. 3 is a schematic diagram of a network device
`according to an embodiment of the present disclosure. The
`45 network device in this embodiment includes:
`a receiving module 301, configured to receive a request
`sent by a terminal for obtaining a file from a network entity
`and receive a data stream carrying the file;
`a recording module 302, configured to record a source
`path carried in the request, wherein the network entity
`providing the file on the source path;
`a detecting module 303, configured to judge whether the
`file is an executable file according to the request or the data
`stream carried the file; and
`a sending module 304, configured to send first alert
`information that carries the source path to a monitoring
`device, if the network device judges the file is the executable
`file.
`In this embodiment, the detecting module detects char(cid:173)
`acteristics of the packet to detect the suspicious code, for
`example, by detecting whether a string which indicating the
`name of the executable file exists in the request; and/or
`detecting whether a file header of the executable file exists
`in the data returned by the server. The recording module
`records the source path of the suspicious code. The sending
`module sends first alert information to the monitoring
`device.
`
`10
`
`55
`
`Juniper Ex. 1001-p. 9
`Juniper v Huawei
`
`

`

`US 10,027,693 B2
`
`7
`This embodiment may further include:
`the receiving module 301 is further configured to receive
`second alarm information sent by the monitoring device
`after further detecting the file downloaded according to the
`source path by the monitoring device, where the second 5
`alarm information includes maliciousness of the suspicious
`code, or includes both the maliciousness of the suspicious
`code and the Botnet topology information.
`Accordingly, this embodiment may further include:
`a first intercepting module 305, configured to intercept 10
`suspicious codes that are malicious according to malicious(cid:173)
`ness of the suspicious codes; or
`a second intercepting module 306, configured to intercept
`the suspicious codes that are malicious and the packets in the
`Botnet corresponding to the Botnet topology information 15
`according to maliciousness of the suspicious codes and the
`Botnet topology information.
`The network device provided in this embodiment reports
`source path of numerous suspicious codes proactively at the
`earliest possible time, ensures comprehensiveness of the 20
`alert information sources, lays a foundation for shortening
`the time required for overcoming virus threats, and avoids
`the trouble of installing software on the terminal. Moreover,
`the first receiving module receives the alarm information
`from the monitoring device, and therefore, the network 25
`device interrupts malicious codes and the packets in the
`Botnet, which reduces the possibility of the host being
`attacked.
`FIG. 4 is a schematic diagram of the monitoring device,
`comprising:
`a receiving module 401, configured to receive first alert
`information that carries a source path sent from a network
`device;
`a downloading module 402, configured to download an
`executable file according to the source path;
`a detecting module 403, configured to detect the execut(cid:173)
`able file to confirm maliciousness of the executable file; and
`a sending module 404, configured to send second alarm
`information to the network device, wherein the second alarm
`information comprises maliciousness of the executable file, 40
`or comprises both the maliciousness of the executable and
`Botnet topology information.
`FIG. 5 is a schematic diagram of system for alerting
`against unknown malicious codes according to an embodi(cid:173)
`ment of the present disclosure. The system in this embodi- 45
`ment includes the network device 501 and the monitoring
`device 512 shown in FIG. 5.
`An embodiment of the present disclosure provides a
`system for alerting against unknown malicious codes. The
`system collects source path of numerous suspicious codes 50
`proactively at the earliest possible time, ensures compre(cid:173)
`hensiveness of the alert information sources, lays a founda(cid:173)
`tion for shortening the time required for overcoming virus
`threats, and avoids the trouble of installing software on the
`terminal.
`After reading the foregoing embodiments, those skilled in
`the art are clearly aware that the embodiments of the present
`disclosure may be implemented through hardware, or, pref(cid:173)
`erably in most circumstances, through software in addition
`to a necessary universal hardware platform. Therefore, all or 60
`part of the novelty of the present disclosure may be embod(cid:173)
`ied in a software product. The software product may be
`stored in storage media such as a read-only memory (ROM)
`or random access memory (RAM), magnetic disk, or Com(cid:173)
`pact Disc Read-Only Memory (CD-ROM), and incorporate 65
`several instructions for instructing a computer device (such
`as personal computer, server, or network device) to execute
`
`35
`
`30
`
`55
`
`8
`the method specified in any embodiment of the present
`disclosure or a part of the embodiment.
`Finally, it should be noted that the above embodiments are
`merely provided for describing the technical solutions of the
`present disclosure, but not intended to limit the present
`disclosure. It is apparent that persons skilled in the art can
`make various modifications and variations to the disclosure
`without departing from the spirit and scope of the disclosure.
`The present disclosure is intended to cover the modifications
`and variations provided that they fall in the scope of pro(cid:173)
`tection defined by the following claims or their equivalents.
`What is claimed is:
`1. A method for alerting against unknown malicious
`codes, th