WO2016014178A1 - Identification de dispositifs de réseau infectés logiciels malveillants par surveillance du trafic - Google Patents

Identification de dispositifs de réseau infectés logiciels malveillants par surveillance du trafic Download PDF

Info

Publication number
WO2016014178A1
WO2016014178A1 PCT/US2015/036120 US2015036120W WO2016014178A1 WO 2016014178 A1 WO2016014178 A1 WO 2016014178A1 US 2015036120 W US2015036120 W US 2015036120W WO 2016014178 A1 WO2016014178 A1 WO 2016014178A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
packet
network traffic
packets
exiting
Prior art date
Application number
PCT/US2015/036120
Other languages
English (en)
Inventor
David HEILIG
Original Assignee
Heilig David
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US14/336,004 external-priority patent/US10659478B2/en
Priority claimed from US14/635,761 external-priority patent/US10313372B2/en
Application filed by Heilig David filed Critical Heilig David
Publication of WO2016014178A1 publication Critical patent/WO2016014178A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms

Definitions

  • the present invention generally relates to detecting malicious network activity coming from computers, routers, and firewalls. Specifically, embodiments of the present invention provide for detecting stealth malware on a host computer by comparing the network traffic known to the host with the network traffic actually going to and from the host. Embodiments of the present invention also provide for detecting stealth malware on a network device by comparing inbound and outbound network traffic to discover packets originating from the network device and packets that violate configuration rules. When combined with a network traffic monitor server configured to monitor actual network traffic reports and to receive known network traffic reports from host computers, the system can detect stealth network traffic originating from both network devices and host computer systems.
  • malware writers are adapting by becoming stealthier.
  • Stealth techniques can hide many aspects of a malware infection on a system from the user, from the operating system, and from host based security software.
  • Malware can run in environments outside of the operating system, including the BIOS or on devices such as a graphic or network card.
  • Hardware implants such as the type used for espionage, also allow attackers to circumvent any host based security. These types of infections cannot be detected with any tool running on the compromised machine. Therefore, in order to identify advanced infections one must look at the activity outside of the machine itself.
  • One of the best places to look for advanced infections is network communications because almost all malware requires network access to perform functions such as receiving additional instructions, transferring stolen information or infecting additional machines.
  • This method of detection is unable to find unknown malware, and is computationally intensive because it requires comparing data snippets from both legitimate and malicious sources with a large database of known malware signatures.
  • the proposed method the mere existence of a packet that has not been seen by the accepted data pathways is indication enough of a possible malicious compromise.
  • U.S. Patent No. 8,079,030 to Satish et al. which runs within a hypervisor to monitor a virtual machine.
  • a hypervisor is a piece of software that runs on the hardware of a single machine, and provides a layer of abstraction and virtual hardware to Operating Systems (OSs) that run on it. This means that the scope of the hypervisor's ability to monitor network communications is limited to a single physical machine. A hypervisor cannot monitor an entire network of independent physical machines.
  • a hypervisor runs on the same physical machine that may be infected with malware. This makes the hypervisor susceptible to the same type of tactics the malware uses against the OS.
  • malware is typically programmed to infect and run on personal computers and servers with standard operating systems (OSs) installed. These types of machines are common and often inadequately protected from malware attacks. The ease with which a piece of malware can find an unprotected standard OS computer is one reason why most malware is written to infect these systems. However, malware can also be written to infect non-standard or application-specific OSs, such as the software that runs on and manages firewalls, routers, and other network infrastructure devices.
  • OSs operating systems
  • Linux and they run applications specific to the functionality of the device. Just like a regular computer, these devices can become infected with malware. But there are no easy ways to determine whether a network device is compromised by examining the device itself. Because they are mostly closed systems, it is not possible to install third-party security software on the device. A network administrator can examine the device and settings of the system, but sufficiently advanced malware could spoof any data presented back to the administrator. If there is a hardware implant then detection is pretty much impossible from just examining device settings.
  • IDSs Intrusion detection systems
  • IDSs can detect malware infections of the network hardware, but IDSs are typically signature-based solutions which means the device must know about the existence of a particular attack before it can be detected. If the router or firewall is compromised with a new or novel piece of malware, there will be no known signatures for it and as long as it sends packets that conform to RFC standards with proper headers and normal- looking payloads, there is nothing to tell the IDS that the packet is from a malicious source.
  • Compromised networked devices are particularly insidious for a number of reasons.
  • a router or firewall has access to all network traffic which means the malware could harvest data as it passes through to be exfiltrated at a later time.
  • these devices could protect all other devices from compromise. So if the firewall is compromised, it could allow in or out data that otherwise would not be allowed.
  • there is no easy way to monitor these devices so users must make major assumptions that the manufacturer built a solid device with no bugs and that the device was not tampered with at any time. Both of these are difficult to guarantee.
  • a computer implemented method for detecting stealth network traffic comprises: receiving at a server a known network traffic report corresponding to a host computer system, wherein the host computer system and the server are separate physical machines, and wherein the known network traffic report comprises information about all network traffic known to an operating system of the host computer system; receiving a network capture report, wherein the network capture report comprises information about actual network traffic corresponding to the host computer system; and comparing individual packet header information from the known network traffic report to individual packet header information from the network capture report to identify stealth network traffic, wherein the stealth network traffic is actual network traffic corresponding to the host computer system which was not known to the operating system running on the host computer system.
  • a computer implemented method for detecting stealth network traffic comprises: receiving a known network traffic report corresponding to a host computer system, wherein the known network traffic report comprises information about all network traffic known to an operating system of the host computer system; receiving a network capture report from one or more taps (network capture devices) on a separate physical machine from the host computer system, wherein the network capture report comprises information about actual network traffic corresponding to the host computer system; and comparing individual packet header information from the known network traffic report to individual packet header information from the network capture report to identify stealth network traffic, wherein the stealth network traffic is actual network traffic corresponding to the host computer system which was not known to the operating system running on the host computer system.
  • the computer-based system further comprises one or more taps (network capture devices) for capturing the network traffic necessary to produce the network traffic report.
  • a computer-based system for detecting stealth network traffic comprises: a server module configured to receive a known network traffic report corresponding to a host computer system on a separate physical machine from the server module; receive a network capture report, wherein the known network traffic report comprises information about all network traffic known to an operating system of the host computer system, and wherein the network capture report comprises information about actual network traffic corresponding to the host computer system; and a calculation module configured to compare individual packet headers from the known network traffic report to individual packet headers from the network capture report to identify stealth network traffic, wherein the stealth network traffic is actual network traffic corresponding to the host computer system which was not known to the operating system running on the host computer system.
  • a system for detecting malware in network devices comprises a first network tap; and a first network monitor server configured to: receive entering network packets and exiting network packets corresponding to one or more network devices, determine matching packets between said entering network packets and said exiting network packets, generate an alert when no matching entering packet can be determined for one or more exiting packets.
  • the system further comprises a second network tap; and wherein said first network monitor server is further configured to: receive LAN side network traffic from said first network tap, receive WAN side network traffic from said second network tap.
  • the system is further configured to: detect unauthorized packets by finding exiting packets without a corresponding entering packet, detect exiting packets with modified payloads by comparing a hash corresponding to each exiting packet to a hash of one or more entering packets, detect a LAN side exiting packet which does not have a corresponding LAN side entering packet that is a request for said LAN side exiting packet.
  • the system is further configured to compare entering packets collected at time T to exiting packets collected within a time frame beginning at time T and ending at time T plus a delta time value.
  • the system of claim 1 wherein said first network monitor server is further configured to: receive a configuration profile corresponding to said one or more network devices, detect an exiting packet which violates one or more rules in said configuration profile.
  • the system is further configured to: receive a known network traffic report corresponding to a host computer system on a separate physical machine from said first network monitor server, wherein said known network traffic report comprises information about all network traffic known to an operating system of said host computer system; and compare individual packet headers from said known network traffic report to individual packet headers from said entering network packets and/or said exiting network packets to identify stealth network traffic not reported in said known network traffic report.
  • the system further comprises a server module configured to: receive a known network traffic report corresponding to a host computer system on a separate physical machine from said server module, wherein said known network traffic report comprises information about all network traffic known to an operating system of said host computer system, receive network traffic information corresponding to said entering packets and said exiting packets; a calculation module configured to compare individual packet headers from said known network traffic report to packet header information from said entering packets and/or said exiting packets to identify stealth network traffic not reported in said known network traffic report.
  • the system is further configured to: select at least one NAT -modified packet to compare to at least one original packet; compare packet header information that is not modified by NAT of said at least one NAT-modified packet to corresponding packet header information of said at least one original packet, wherein said packet header information is selected from the group consisting of: source IP address, source port, destination IP address, and destination port; perform an original packet hash on one or more of packet payload, source IP address, source port, destination IP address, and destination port of said at least one original packet; compare said original packet hash to a corresponding hash of said at least one NAT-modified packet.
  • the system is further configured to compare one or more TCP packet attributes of said at least one NAT-modified packet to corresponding TCP packet attributes of said at least one original packet, wherein said one or more TCP packet attributes are selected from the group consisting of: sequence number, acknowledge number, and TCP checksum.
  • the system is further configured to compare packet payload size of said at least one NAT -modified packet to payload size of said at least one original packet.
  • a method for detecting malware in network devices comprises the steps of: receiving network traffic information corresponding to entering packets and exiting packets of one or more network devices; comparing entering packets to exiting packets; determining exiting packets which do not have a corresponding entering packet.
  • the method further comprises the steps of: computing an exiting packet hash based, at least in part, on an exiting packet payload; computing an entering packet hash based, at least in part, on an entering packet payload; comparing said exiting packet hash to said entering packet hash.
  • the method further comprises the steps of: recording entering packets which are outbound requests for data; comparing one or more inbound packets to said outbound requests for data; detecting one or more inbound packets which do not have a corresponding said outbound request for data.
  • the method further comprises the steps of: receiving a known network traffic report corresponding to a host computer system, wherein said known network traffic report comprises information about all network traffic known to an operating system of said host computer system; and comparing packet header information from said known network traffic report to packet header information from said entering packets and/or said exiting packets to determine packets which are not reported in said known network traffic report.
  • the method further comprises the step of comparing one or more entering packets collected at time T to one or more exiting packets collected within a time frame beginning at time T and ending at time T plus a delta time value. [0030] The method further comprises the step of comparing at least one of source IP address, source port, destination IP address, and destination port of an exiting packet to corresponding header information of an entering packet
  • the method further comprises the steps of: computing an entering hash based on said entering packet, computing an exiting hash based on said exiting packet, comparing said entering hash to said exiting hash, determining that said exiting packet is a NAT-modified version of said entering packet based on comparison of said entering hash and said exiting hash.
  • the method further comprises the step of comparing payload size of said entering packet with payload size of said exiting packet.
  • the method further comprises the step of comparing at least one of TCP sequence number, TCP acknowledge number, and TCP checksum between said entering packet and said exiting packet.
  • FIG. 1 is a high-level diagram of the various components in one embodiment of the present invention interconnected through a network;
  • FIG. 2 is a block diagram of an exemplary host computer system, showing how the monitoring and reporting module accesses, records, and reports known network traffic and how malware hides network traffic from the operating system;
  • FIG. 3 shows a block diagram of one embodiment of the central processing server, its various components and how they interact with each other and the other devices on the network;
  • FIG. 4 is a flowchart depicting the operation of the monitoring and reporting module
  • FIG. 5 is a flowchart depicting the high-level operation of the central processing server
  • FIG. 6 is a flowchart depicting the detailed operation of the calculation module which performs comparisons between known network traffic and actual network traffic to detect stealth network traffic.
  • FIG. 7 is a diagram of a network device monitoring system according to an embodiment of the present invention.
  • FIG. 8 is a block diagram of a network device monitor server according to an embodiment of the present invention.
  • FIG. 9 is a flowchart depicting the steps for detecting malware that may be attempting to send data out of the network from a network device according to an embodiment of the present invention.
  • FIG. 10 is a flowchart depicting the steps for detecting malware that may be attempting to modify packets heading out of the network from a network device according to an embodiment of the present invention
  • FIG. 11 is a flowchart depicting the steps for detecting unauthorized inbound network traffic that does not have a corresponding outbound request according to an embodiment of the present invention
  • FIG. 12 is a diagram showing a network device monitoring system with multiple network device monitor servers according to an embodiment of the present invention
  • FIG. 13 is a diagram of a network device monitoring system comprising a network device monitor server, a router traffic monitor server, and system agents including monitoring and reporting modules installed on host machines according to an embodiment of the present invention
  • FIG. 14 is a flowchart depicting the steps for detecting malware infecting one of multiple network devices within a network according to an embodiment of the present invention.
  • Fig. 15a is a flowchart depicting a method for finding a set of NAT-modified packets potentially matching an original packet where the source IP address is modified by NAT and no lookup table is available according to an embodiment of the present invention.
  • Fig. 15b is a flowchart depicting a method for finding a set of NAT-modified packets potentially matching an original packet where the source IP address and source port are modified by NAT according to an embodiment of the present invention.
  • FIG. 16 is a flowchart depicting a method for narrowing down a set of NAT-modified packets potentially matching an original packet and comparing the original packet to the set of NAT-modified packets to determine if any of the NAT-modified packets actually match the original packet according to an embodiment of the present invention.
  • the present invention generally relates to detecting malicious network activity coming from computers, routers, and firewalls. Specifically, embodiments of the present invention provide for detecting stealth malware on a host computer by comparing the network traffic known to the host with the network traffic actually going to and from the host. Embodiments of the present invention also provide for detecting stealth malware on a network device by comparing inbound and outbound network traffic to discover packets originating from the network device and packets that violate configuration rules. When combined with a network traffic monitor server configured to monitor actual network traffic reports and to receive known network traffic reports from host computers, the system can detect stealth network traffic originating from both network devices and host computer systems.
  • Fig. 1 illustrates the basic operation of the present invention and the various components interconnected through network data paths 101.
  • a network capture device 102 sits in a position on the network where it can capture all the required network traffic on the network data paths 101.
  • the required network traffic is defined by all network traffic corresponding to the host computer systems 103 that are being monitored. For example if an entire network is to be monitored, the network capture device 102 should be placed at a point where it will be able to see all the network traffic. This position may be between the network and a larger network or Wide Area Network (WAN) 107, such as the internet; or the network capture device 102 may be at some other advantageous position depending on the topology and design of the individual network.
  • WAN Wide Area Network
  • the function of the network capture device 102 could even be accomplished by using multiple network capture devices 102 strategically placed throughout the network such that, when combined, they together collect all the network traffic corresponding to the host computer systems 103 that are being monitored. In the trivial case of monitoring a single host computer system 103, the network capture device 102 may be incorporated into the host computer system 103 being monitored, or be attached just outside the host computer system 103.
  • One of ordinary skill in the art would recognize there are a variety of means for capturing all required network traffic through a single device or multiple devices distributed throughout the network, and embodiments of the present invention are contemplated for use with any means for capturing required network traffic.
  • the network capture device 102 is on a separate physical machine from the host computer system 103 being monitored. Being on a separate physical machine means it is either its own piece of dedicated hardware, or incorporated into the hardware of a larger computer system independent from the host computer system.
  • the primary advantage of this is that it ensures that the network capture device 102 will not be affected by malware 202 that may be running on one or more host computer systems 103. This also allows some degree of freedom to strategically place the network capture device where it can collect the required network traffic corresponding the host computer systems 103 being monitored.
  • data captured by the network capture device 102 is compiled into a network capture report 105.
  • the network capture device 102 may be configured to automatically generate network capture reports 105 periodically, or it may be configured to respond to queries 105, or it may merely store the captured data in a database within the network capture device 102 or elsewhere on the network where another component can access the data to generate the network capture reports 105.
  • a network capture report need not comprise all traffic on a network, and multiple network traffic reports each generated by a separate device on the network could be combined to capture all required network traffic.
  • One of ordinary skill in the art would recognize that there are a variety of ways to accomplish the task of creating network capture reports 105.
  • One of the advantages of the present invention is that the actual payload of packets does not need to be copied or inspected. All the information required for detecting stealth network traffic is in the packet header. This greatly reduces the amount of storage space required by the present invention, increases the speed with which a network capture report 105 can be transmitted and analyzed, and reduces overhead on the network and computing power required of the central processing server 104.
  • one or more host computer systems 103 are also connected to the network data paths 101. Each of these host computer systems 103 gathers information about the network communications known to an Operating System (OS) running on that particular host computer system 103. The information about the network communications known to the OS is compiled into a known network traffic report 106. Both the known network traffic report 106 and the network capture report 105 are sent to the central processing server 104, where they are compared. Any traffic to or from a host computer system that shows up in the network capture report 105 but not in the same host computer system's known network traffic report 106 is considered stealth network traffic and causes an alert to be generated.
  • OS Operating System
  • the alert can be as simple as a notification that stealth network traffic was found. It may also indicate which host computer is responsible for the stealth network traffic.
  • one of the advantages of the present invention is that discovering which individual packets caused the alert is trivial because these packets are naturally identified in the comparison between known network traffic and captured network traffic. The information from the headers of these packets could be included in detailed information about the alert so that a qualified network manager can interpret the alert and decide how to address it.
  • the network capture device keeps a temporary log of all network traffic captured, including packet payload.
  • One of ordinary skill in the art would recognize there are a variety of ways to issue an alert and a variety of levels of detail that an alert can include.
  • Fig. 2 shows a host computer system 103 that may be infected with malicious software, or malware 202.
  • Advanced malware 202 may run within or outside the OS 203.
  • the malware 202 may use network communication hardware, such as the Network Interface Card (NIC) 204 by circumventing legitimate network channels 205 of communication established by the OS 203.
  • Network communication that does not use the legitimate network channels 205 established by the OS is considered stealth network traffic 211.
  • NIC Network Interface Card
  • a monitoring and reporting module 208 is installed on the host computer system 103. This monitoring and reporting module 208 interfaces with the legitimate network channels 205 established by the OS 203 of the host computer system 103 and creates a known network traffic report 106 from the packet headers of all known network traffic 212 sent over the legitimate network channels 205. Like the network capture report 105, all the information required for the known network traffic report 106 can be obtained from packet headers.
  • the preferred method of creating the known network traffic report 106 is through a software -implemented monitoring and reporting module 208 installed on the host computer system's 103 Operating System 203. This eases implementation on a network with a large number of host computer systems and provides built- in access to the data required, depending on the OS.
  • the monitoring and reporting module 208 It is particularly advantageous for the monitoring and reporting module 208 to have access to the packet headers of all known network traffic 212 sent through legitimate network channels 205 and only known network traffic 212 sent through legitimate network channels 205.
  • the fact that stealth network traffic is unknown to the OS is the very thing that makes it detectable by the present invention. Therefore, giving the monitoring and reporting module 208 access to the lower levels of network traffic where the malware 202 might be hiding its network traffic would only serve to reduce the ability to detect malware.
  • the data required for the known network capture report 106 may be gathered by a variety of means, including, but not limited to, hooking into the appropriate framework provided by the OS 203, piggy-backing onto another piece of host security 207 software, or by accessing a log file generated by the OS 203 or a resident program.
  • hooking into the appropriate framework provided by the OS 203 piggy-backing onto another piece of host security 207 software, or by accessing a log file generated by the OS 203 or a resident program.
  • One of ordinary skill in the art would recognize that depending on the OS 203 there will be a variety of ways to gain access to the data required to produce the known network traffic report 106.
  • either the known network traffic report 106, or the network capture report 105 or both are transmitted to the central processing server 104 over the network using encrypted communications.
  • This provides a way to prevent and detect tampering by a piece of malware 202 that might try to spoof the communications between the monitoring and reporting module 208 and the central processing server 104.
  • This encryption makes it much more difficult for malware 202 to insert its own traffic into the known network traffic report 106, or pose as a monitoring and reporting module and send its own known network traffic reports 106. Either of these activities on the part of malware 202 would produce data corruption or inconsistencies in the known network traffic reports that would be trivial for the central processing server 104 to detect.
  • Fig. 3 shows a block diagram of a central processing server 104.
  • a server module 301 is configured to initiate network connections or accept network connections from other devices on the network.
  • the server module 301 receives known network traffic reports 106 corresponding to host computer systems 103 and network capture reports 105 from the network capture device 102 over the network connection 302 and sends them to the database module 303.
  • the database module 303 stores data used to perform the various calculations for detecting stealth network traffic and the results of those calculations.
  • the calculation module 304 is the heart of the central processing server 104, as it performs the comparison between the known network traffic reports 106 and network capture reports 105 received over the network connection 302.
  • the calculation module 304 identifies stealth network traffic 211 by comparing network traffic corresponding to a particular host computer system 103 with known network traffic 212 reported by the same host computer system 103. This comparison is performed for each host computer system 103 with a monitoring and reporting module 208 installed, and the results are stored with the database module 303. If stealth network traffic 211 is detected, the alert module 305 sends an alert to the appropriate personnel.
  • a user interface module 306 allows for manual configuration of the central processing server in whatever way is convenient or useful. Manual configuration may be done either locally or remotely via a configuration connection 307. Manual configuration allows, among other things, designating certain devices on the network that do not send known network traffic reports 106, such as network management hardware, IP phones, game consoles, or multimedia streaming devices, etc. These devices are either unlikely to be infected with malware 202, or incapable of installing and running third-party software, such as the monitoring and reporting module 208. Eliminating them from data analysis allows the central processing server 104 to collect and analyze less than all of the actual network traffic, further reducing computational power requirements.
  • Various other possible configuration options include, but are not limited to, setting alert thresholds, defining where and how alerts should be sent, choosing network traffic to ignore, auto-detecting host computer systems 103 with and without the monitoring and reporting module 208 installed, etc.
  • the central processing server 104 may be implemented either as a standalone physical unit dedicated to the tasks of the central processing server described above, in hardware, firmware, or in software running on a general purpose server on the network.
  • the central processing server 104 may also be integrated into the same system with the network capture device 102 or simply interface with network capture-capable hardware already deployed on the network.
  • One or ordinary skill in the art would recognize that there are a variety of ways to implement the central processing server without departing from the spirit and scope of the invention.
  • the monitoring and reporting module 208 which runs on the host computer systems 103 will now be explained in greater detail with reference to the flowchart in Fig. 4.
  • the monitoring and reporting module 208 collects network traffic data from the OS.
  • the specific method of gaining access to this information is dependent upon the OS, or other software installed on the system. Methods of accessing network traffic data on an OS are generally well documented and widely used by third- party internet security programs to provide data security services.
  • the only data required by the central processing server 104 can be obtained by extracting packet headers of IPv4, IPv6, or any other network protocol packets, as shown in step 402.
  • Step 403 stores traffic data in the network traffic database 410.
  • the traffic data in the network traffic database 410 will later be included in the known network traffic report 106.
  • the monitoring and reporting module decides whether to send a known network traffic report 106 to the central processing server 104.
  • Sending the known network traffic report 106 can be done at the expiration of a timer, upon receiving a request from the central processing server, or after a specific number of packets have been processed, etc.
  • the known network traffic report 106 could also be stored at a network location where the central processing server 104 could access it as needed.
  • One of ordinary skill in the art would recognize that there are a variety of ways give the central processing server 104 access to the known network traffic report 106, and also to decide when to send reports, and any one method or a combination of methods could be used as needed.
  • the monitoring and reporting module 208 gathers data from the network traffic database 410 to generate a known network traffic report 106 in step 405 and sends it to the central processing server 104 in step 404.
  • Fig. 5 shows a flowchart of the operation of the central processing server 104.
  • the central processing server 104 waits for data to be available. Waiting does not have to be for any appreciable amount of time and the central processing server need not wait at all. If data is already available, the central processing server 104 will proceed immediately to step 502 without waiting and receive a known network traffic report 106 from the host computer system 103.
  • the central processing server 104 then receives a network capture report 105 from the network capture device 102 in step 503.
  • the data from the network capture report 105 and known network traffic report 106 is stored in the database module 303.
  • the central processing server 104 compares the actual traffic with the known network traffic 212 to or from a host computer system 103. If any discrepancies (indicating stealth network traffic) were discovered, an alert is generated in step 505.
  • Fig. 6 gives a detailed flowchart for the operation of the calculation module.
  • the calculation module 304 iterates to the next host computer system.
  • the calculation module 304 analyzes the network traffic corresponding to one host computer system 103 at a time.
  • the calculation module 304 pulls the host computer system's 103 known network traffic 212 from the database module 303, then, in step 603, pulls the host computer system's 103 actual traffic from the database module 303.
  • the calculation module compares, in step 604, the known network traffic 212 to the actual network traffic, as reported by the network capture device 102.
  • Any traffic that belongs to the particular host computer system 103 but does not show up in the known network traffic report 106 for the same host computer system 103 is considered stealth network traffic 211.
  • the results of this comparison are sent back to the database module 303, in step 605. If any discrepancies were found, an alert is generated for the appropriate host computer system 103 in step 606.
  • Fig. 4-6 need not be performed in the exact order as described, and another storage structure could take the place of the database module.
  • the requirement for a monitoring and reporting module 208 running on the host computer system 103 may be satisfied by a separate piece of software created by a third party that generates data, possibly for an unrelated purpose, suitable for use in the present invention.
  • the important aspect is that information about the known network traffic be made available to the central processing server 104.
  • the embodiment of the central processing server described is one of many possible embodiments of the present invention.
  • the specific modules described could be combined, either partially or wholly, or separated into more specialized modules.
  • inbound will be used to refer to network traffic entering the network or subnet from outside, for example WAN side to LAN side on a firewall.
  • outbound refers to network traffic leaving the network, or packets heading from the LAN side to the WAN side of the network device.
  • Entering packets or entering traffic are packets or network traffic received by the network device or entering the network device regardless of which side of the device (WAN or LAN) they are entering from.
  • exiting packets or exiting traffic are packets or network traffic leaving the network device or passed on by the network device toward the final destination.
  • a packet has many layers where each layer contains a header and a payload.
  • the payload of the lower layers contains the header and payload of the next higher layer. Therefore, the term payload may refer to both the header and payload together of a higher level layer.
  • header information at any layer is referred to as the header and the user data payload is referred to as the payload.
  • the payload is referred to as the payload.
  • a network device monitoring system of the present invention can be described as comprising a network device monitor server and one or more network taps or network capture devices.
  • the network taps tap into network communications and copy network traffic to the network device monitor server.
  • the network device monitor server compares entering and exiting network traffic to determine if any stealth packets or otherwise unauthorized packets exist.
  • Stealth packets are network traffic that shows up on the network but is unknown to any of the devices which are authorized to produce network traffic. Stealth traffic may appear to originate from a specific machine on the network, but does not show up in that machine's network traffic reports. More specifically, when monitoring a firewall or router the network device monitor server will collect outgoing traffic on the LAN side and compare it to outgoing traffic on the WAN side. If there are any packets on the WAN side which were not seen on the
  • the network device monitoring sever determines that the packet was sent from the network device itself and generates an alert.
  • the network device monitor server can also detect unauthorized inbound network traffic and illegally modified packets.
  • Many network devices are able to update their own firmware or send messages to each other to coordinate and optimize network traffic routing. When sending messages to other network devices, network devices use special protocols (OSPF, RIP, BGP, etc) that are encapsulated within layer 2, 3, and 4 of the OSI model protocols. This kind of network traffic can be mistaken for malware-generated traffic because it originates from the network device itself.
  • OSPF OSPF, RIP, BGP, etc
  • the network device monitor server can also be combined with the stealth packet detection system of the parent application entitled “Identifying Stealth Packets in Network Communications Through the Use of Packet Headers” filed July 21, 2014, incorporated by reference herein.
  • a network monitor server retrieves network traffic from the firewall tap on the LAN side and receives reports of actual network traffic from the central processing server, or gathers information on network traffic from other network taps or network capture devices. The network monitor server then compares network traffic on the LAN side of the firewall to actual network traffic to and from the host machines on the network. If there are discrepancies, then one of the network devices within the network may be infected with malware or otherwise compromised.
  • FIG. 7 illustrates how a network device monitor server 102 of the present invention interfaces with a network device 101 for malware detection and traffic monitoring according to an embodiment of the present invention.
  • a first tap 105 is placed on the WAN side of the network device 101 and a second tap 106 is placed on the LAN side of the network device 101.
  • the taps 105, 106 should be placed such that they are able to see all incoming network traffic 103 and all outgoing network traffic 104.
  • the network device 101 is a firewall, properly tapping the connections is fairly simple because there is typically a single physical connection on each of the WAN side and the LAN side.
  • the WAN side typically still only has a single physical connection, but the LAN side may have multiple physical connections.
  • the individual LAN side ports can each be tapped individually, or they may be aggregated into a single port by using a port aggregator, a network switch, or any device that provides a single data stream from multiple data streams.
  • port aggregators and switches that do not run software are not vulnerable to software -based malware, they may still be vulnerable to physical bugs. This risk can be mitigated by physically securing network hardware.
  • the taps 105, 106 make a copy of network traffic and the copy is sent to the network device monitor server 102.
  • the network device monitor server can detect unauthorized network traffic by examining only the information in the packet headers, without examining the actual user data payloads of the packets. This is possible because the very existence of a packet on one side of the network device when the same packet never showed up on the other side of the network device indicates that the packet came from within the network device itself and is unauthorized. In some situations, such as when Network Address Translation (NAT) is used, it is desirable to compare a hash of the payload or other payload metadata, but it is not necessary to directly use the contents of the user data payload.
  • NAT Network Address Translation
  • the network device monitor server 102 may reside on a dedicated physical machine or may be one of many network device monitor servers that reside on a network management server physical machine. Other network device monitor servers monitoring other portions of the network may also reside on the network management server together with the network device monitor server 102.
  • the network device monitor server 102 is implemented as a software module running on a physical machine.
  • the network device monitor server 102 is implemented in hardware or with a combination of hardware, firmware and/or software.
  • the network device monitor server 102 may be implemented with any mix of hardware, firmware, and software without departing from the spirit and scope of the present invention.
  • the network device monitor server 102 may also obtain a network device configuration profile 107 from the network device 101.
  • the configuration profile 104 may include firewall settings, port forwarding, or other network management settings.
  • the network device monitor server may then compare network traffic from the taps 105, 106 to the configuration profile 107 in order to verify that the network device or firewall is actually behaving correctly.
  • FIG. 8 shows a block diagram of a network device monitor server 102 according to a preferred embodiment of the present invention.
  • a server module 201 coordinates communication with the WAN side tap 105 and the LAN side tap 106 to collect network traffic information.
  • the server module 201 receives network traffic from the taps 105, 106, and sends it to the database module 203.
  • the database module 203 stores data used to perform the various calculations or comparisons and the results of those calculations or comparisons.
  • the calculation module 204 is the heart of the network device monitor server 104, as it performs the comparison between the LAN side network traffic 106 and WAN side network traffic 105.
  • the calculation module 204 identifies unauthorized network traffic, stealth packets, or packets originating from the network device by (1) comparing WAN side traffic to LAN side traffic, (2) comparing network traffic to outgoing requests, and (3) comparing network traffic to a configuration profile 107. The results of these comparisons are stored with the database module 203. If unauthorized network traffic 211 is detected, the alert module 205 sends an alert. Detailed descriptions of the algorithms used to detect unauthorized outbound traffic, modified packets, and inbound traffic are disclosed below with reference to Figs. 9-11.
  • Fig. 9 shows a flowchart depicting the process of detecting unauthorized outbound network traffic.
  • Outbound network traffic is network traffic moving from the LAN side of a network device to the WAN side of a network device.
  • unauthorized outbound traffic is malware trying to send stolen data outside the network.
  • malware may collect data from the network traffic and then repackage it and send it home.
  • the network device monitor server will detect this kind of unauthorized traffic or any network traffic originating within the network device it monitors through the process described in Fig. 9.
  • the network device monitor server 102 receives packet information corresponding to outbound packets from the LAN side tap 106 at the server module 201.
  • the network device monitor server 102 receives packet information from the WAN side tap 105 at the server module 201. Packet information is stored in the database module 203. Although only packet headers are required to detect unauthorized outbound or inbound traffic without NAT, the taps 105, 106 will send a full copy of network traffic, so that the server module 201 or calculation module 204 can extract the packet header and other required information from the packet which is required for detecting unauthorized network traffic.
  • step 303 the calculation module 204 then compares the WAN side outbound packet headers to the LAN side outbound packet headers.
  • step 304 if there are packet headers collected from the WAN side that do not show up in the packet headers collected from the LAN side, then the packet originated from the network device 101 and an alert is generated from the alert module 205 in step 305.
  • An alert may be generated by sending an email, text message, creating a log entry or log file, or any other electronic means of notifying a system administrator or creating a record of the detected anomaly.
  • Any method of notifying administrators or generating an alert could be used without departing from the spirit and scope of the present invention. If no discrepancies are found, the network device monitor server 102 continues to monitor traffic by returning to step 301.
  • Fig. 10 shows a flowchart for a method of detecting outbound packets that are modified by malware residing on the network device. Although the method of Fig. 9 can detect stealth packets that originate from the network device, it will fail to detect otherwise legitimate packets that have been modified to carry a malicious payload or steal data from within the network device.
  • the network device monitor server 102 receives outbound packets from the LAN side tap 106 at the server module 201.
  • the network device monitor server 102 receives outbound packets from the WAN side tap 105 at the server module 201.
  • the server module 201 computes hash values of the packets from both the LAN side and the WAN side.
  • the packet payload could be compared directly, but hashing helps to protect data privacy, and reduces computational power required when the same packets are being compared multiple times.
  • the hash function used on packets may be MD5, SHA, or any other hash function suitable for generating unique values that are relatively easy to compare from large inputs.
  • malware If malware is able to modify packets within a network device, it would be trivial to modify the packet payload without making any changes to the header. Therefore, hashing the packet payload provides a method of detecting this kind of unauthorized modification.
  • the first and second strategy are not mutually exclusive, and both could be used together or the payload and one or more immutable fields could be combined as input to a single hashing step.
  • One of ordinary skill in the art would recognize that a variety of different portions of the packet payload and header could be hashed individually or in combination in order to detect certain modifications that malware could make to packets to achieve nefarious purposes.
  • the packets and hash computation results are stored with the database module 203.
  • the calculation module 204 compares the hash values of WAN side outbound packets against the hash values of LAN side outbound packets. If there are any hash values that do not correlate or match in step 405, then the corresponding packet was modified within the network device and the alert module 205 generates an alert in step 406. If no discrepancies are found, the network device monitor server 102 continues to monitor traffic by returning to step 401.
  • the processes of Fig. 9 and Fig. 10 can be reversed to detect unauthorized inbound network traffic. Inbound network traffic is network traffic which moves from the WAN side to the LAN side of the network device.
  • Fig. 9 When applied to inbound network traffic, the method described in Fig. 9 detects packets originating from the network device itself.
  • inbound network traffic originating from the network device can be detected through a process similar to that described in Fig. 9, and modified packets can be detected by adapting the process of Fig. 10, there are still some malicious packets which neither of these processes will detect.
  • inbound network traffic In the particular case of a firewall, there is certain inbound network traffic that will be blocked, and other inbound network traffic that will be allowed, according to the configuration profile 107 of the firewall.
  • malware infects the firewall, it may allow malicious packets that should be blocked to leak through the firewall.
  • These unauthorized packets are captured on both the WAN side and LAN side, and remain unmodified, so they will not be detected by either of the strategies described in Fig. 9 and Fig. 10.
  • Step 11 shows a flowchart of a method for detecting unauthorized inbound network traffic that bleeds through a malware-infected firewall.
  • a stateful communication protocol such as TCP (Transmission Control Protocol)
  • TCP Transmission Control Protocol
  • the network device monitor server logs outbound connection requests, storing them with the database module 203.
  • the network device monitor server 102 receives inbound packets from the LAN side tap 106 at the server module 201 and stores the inbound packets with the database module 203.
  • the calculation module 204 checks with the database module 203 for an outbound connection request for each inbound packet collected.
  • Step 504 if there are any mismatches where an inbound packet has been passed through the firewall with no corresponding outbound request, then at Step 505, the alert module 205 generates an alert. If there are no anomalies in the network traffic, the network device monitor server returns to step 501 to continue checking.
  • Stateless communications may be allowed to pass through the firewall by setting up a firewall rule opening a particular communication port. This port information can be included in the network device configuration profile. The network device monitor server can check incoming traffic against this configuration profile to verify that it is being properly allowed or blocked.
  • UDP User Datagram Protocol
  • the network device monitor server 102 is configured to work in a wireless network environment.
  • the WAN side tap remains wired, but the LAN side tap comprises a wireless Network Interface Card configured with the Wi-Fi network channel and security settings and set in promiscuous mode.
  • the wireless NIC picks up all traffic on the wireless LAN and the network device monitor server processes the data to extract packet information to be used for comparison with WAN side traffic. Once network packets are extracted from the wireless data, comparisons proceed in the same manner as a wired network device monitor server.
  • the above description with reference to Figs 7-11 describes an exemplary embodiment and various methods of detecting unauthorized network traffic through a network device monitor server of the present invention.
  • the function of the network device monitor server 102 described herein can be augmented through combination with the central processing server, network capture device and monitoring and reporting modules residing on host computers as described in this application's parent application (Application No. 14/336,004, entitled “Identifying Stealth Packets in Network Communications Through the Use of Packet Headers” filed July 21, 2014).
  • Application No. 14/336,004 entitled "Identifying Stealth Packets in Network Communications Through the Use of Packet Headers” filed July 21, 2014.
  • Fig. 12 shows a diagram of a network with various monitor servers 601, 602, 603 deployed in a complex networking environment comprising a firewall 604, three routers 605, 606 and two subnets 608, 609.
  • the subnets 608, 609 each comprise a plurality of host computer systems 610 with monitoring and reporting agents installed.
  • the monitoring and reporting agents are also known as monitoring and reporting modules in the parent application.
  • the network device monitor server 601 monitors inbound and outbound traffic at the firewall 604 as described above.
  • Each of the subnet monitor servers 603 collects actual network traffic reports from network capture devices, or taps 607 and known network traffic reports from the monitoring and reporting modules running on the host systems 610.
  • the subnet monitor server compares known network traffic to actual network traffic and detects stealth packets sent by malware based on network traffic that was detected but did not show up in the known network traffic report.
  • the operation of the subnet monitor server or central processing server is described in detail in this application's parent application (Application No. 14/336,004, entitled “Identifying Stealth Packets in Network Communications Through the Use of Packet Headers” filed July 21, 2014).
  • an infected router 605 will still be able to send unauthorized network traffic into and out of the network without detection by the network device monitor server 601 or the subnet monitor servers 603.
  • Outbound unauthorized packets originating from the infected router 605 will show up on both the LAN side and WAN side of the firewall 604, and raise no alerts with the network device monitor server 601.
  • Inbound packets originating from the infected router 605 have bypassed the firewall 604 and will not be blocked.
  • router monitor servers 602 are placed at each router or at-risk network device within the network.
  • a router monitor server is the same as the network device monitor server described above, but need not necessarily have features or functionality that are specific to monitoring firewalls. Any modified packets or unauthorized packets originating from the infected router 605 will be detected by the router monitor server 602 monitoring the infected router 605 through the methods described with reference to Figs. 9-11.
  • network capture devices or taps 607 will need to be placed on the WAN side and LAN side of each router 605, 606 within the network.
  • the primary advantage of this setup is that it allows detection of which specific router 605, 606 is the source of unauthorized network traffic originating within the network.
  • the primary disadvantage of this solution is that it requires placing additional taps within the network, increasing the cost and complexity of the monitoring system.
  • the router monitor servers 602 shown in Fig. 12 may be independent physical machines or instances of the same software module running on a single physical server.
  • the functions of the router monitor servers 602 can also be incorporated into a single software module that tracks and monitors the traffic on all the routers 605, 606.
  • One or ordinary skill in the art would recognize that any arrangement or combination of router monitor servers may be used without departing from the spirit and scope of the present invention.
  • FIG. 13 An alternate solution to the problem of unauthorized network traffic originating from network devices within the network is shown in Fig. 13.
  • a single network monitor server 702 can be used.
  • the network monitor server captures network traffic from the existing taps 707a, 707b already used by the network device monitor server 601 and subnet monitor servers 603.
  • the routers 605, 606 are treated as a single network device with the LAN side tap 707a of the firewall 604 acting as the WAN side tap 707a for the network monitor server 702 and the WAN side subnet taps 707b acting as the LAN side taps 707b for the network monitor server 702.
  • Unauthorized network traffic is detected in the same manner as a network device monitor server. In this manner, the internal network devices can be monitored for unauthorized network traffic. However, in the system depicted in Fig. 13, the network monitor server 702 would not necessarily be able to determine which particular router produced unauthorized network traffic that is detected.
  • Fig. 13 represents one embodiment of a basic configuration required to detect stealth packets and other unauthorized network traffic on a network.
  • the methods and processes described herein can be used to detect unauthorized network traffic if the following data is collected: network traffic known to the host systems on the network, actual network traffic within the network, and inbound / outbound network traffic on the WAN side of the network.
  • network monitoring system can make more accurate determinations of which devices may be infected with malware and producing unauthorized network traffic.
  • the function of the network monitor server 702 may be incorporated into one or more subnet monitor servers 603 or the network device monitor server 601. Alternatively, the network device monitor server 601 and subnet monitor server 603 may communicate with each other to share data necessary to discover malware-infected network devices within the network. In another embodiment, a single network monitor server 702 may be configured to perform the functions of the network device monitor server 601 and subnet monitor servers 603, including receiving known network traffic reports and actual network traffic reports for each subnet.
  • monitor servers may be used on the same physical machine or distributed over multiple physical machines, or network data may be sent to a remote location for analysis without departing from the spirit and scope of the present invention.
  • the network monitor system receives captured network traffic information corresponding to the host systems 610 on the network.
  • the network monitor system receives captured network traffic information from the WAN side of the network.
  • the network monitor system compares host system network traffic with WAN side network traffic. If any outbound traffic on the WAN side was not detected from any of the host systems, then a network device has produced the outbound network traffic. If inbound network traffic to the host systems does not have matching inbound network traffic on the WAN side, one of the network devices has produced inbound network traffic.
  • any inbound network traffic to the host systems does not match an outbound request, either the firewall is compromised or malfunctioning, or a network device in the network produced the network traffic. If the hash values of payload data of inbound network traffic at the host systems do not match the hash values of payload data of the inbound network traffic on the WAN side, then one of the network devices has injected an unauthorized payload into that inbound network traffic. If the hash values of payload data of outbound network traffic on the WAN side do not match the hash values of payload data of the outbound traffic from the host systems, then one of the network devices has injected an unauthorized payload into that outbound network traffic. Any mismatches that are detected in step 804, will cause an alert to be generated in step 805. If no anomalous traffic is detected, the network monitor system returns to step 801 to continue collecting and analyzing network traffic.
  • NAT Network Address Translation
  • All forms of NAT involve modifying the IP and/or TCP/UDP packet headers in some way. This can include the source and/or destination IP address as well as source or destination port, depending on the direction of travel. Some NAT implementations also modify the TCP sequence number. The network device will keep a NAT lookup table of source and destination IP address and port numbers to track how outbound and inbound packets were translated.
  • Static NAT uses a one-to-one IP address mapping so the same input will always map to the same output.
  • a static lookup table is generally provided by the network administrator. This static lookup table can be used to determine what inbound and outbound packets will look like after translation. Dynamic NAT is similar to static NAT, but the NAT lookup table is generated on-the-fly. This is slightly more complicated than static NAT, but typically only a single value in the IP packet header is being changed. Overloading NAT involves a many-to-one IP address mapping where there are many local clients using a single IP address on the internet. In addition to the IP address change, overloading also requires changing the source port of the outbound packet. The network device will store this port mapping in an internal lookup table to be used to re-translate the address of inbound packets to be routed to the correct host system. This is what most home and small business routers use. Overlapping NAT is a lot like static NAT but used for when the connections are between two private networks that share a similar address space. Overlapping NAT may change both source and destination IP addresses and ports.
  • NAT devices In addition to the header modification issues, some NAT devices also cause packet fragmentation or will combine fragments before performing translation. What this means is that a single outbound packet may be seen as one packet on the LAN side outbound but as 1+N packets on the WAN side outbound. Or multiple packets on one side will be combined in a single packet on the other side. Packet fragmentation and combination can happen on either outbound or inbound packets.
  • we need to combine fragmented packets into a single packet in order to find a comparable combined packet produced by the network device we examine the fragment flag and fragment offset value along with other header attributes. Although the order in which the packet fragments are recorded from the tap and inserted in the database is likely to be the order that they need to be recombined in, it is good to verify that the recombination is correct by checking packet header values.
  • the network device monitor server 102 collects IP packets from the network traffic and stores them with the database module 203. Since packet headers are modified by NAT, a simple query of the database will not necessarily bring up the desired packets from each side (LAN side and WAN side) of the network device. However, given an original packet entering the network device that has not yet been translated, we can search for exiting packets that fall within a certain timeframe to narrow down the possibilities.
  • a maximum delta time value can be set which represents a maximum amount of time lapsed from the time stamp of the original packet. The amount of time it takes to process a packet is very small, so a delta time value of perhaps a few hundred nanoseconds could be used in many cases.
  • the delta time value can also be adjusted dynamically based on current load conditions on the network device. As load increases and it takes longer to process packets, the delta time value can increase in response to that timing change.
  • One of ordinary skill in the art would be able to determine an appropriate delta time value for a particular model network device. A query for potentially matching packets in the database based on an original packet's time stamp would return all packets within the timeframe defined by the original packet's time stamp plus the delta time value.
  • Packets that enter the network device such as packets addressed for local delivery only, but do not have a matching packet leaving the device are likely dropped packets that can be removed from the overall tally.
  • the network device monitor server begins processing the packets collected from both sides of the network device to determine if any packets exiting the network device do not have a corresponding packet entering the network device.
  • Fig. 15a shows a flowchart for comparing IP packet headers when a static lookup table is not available or dynamic NAT is used.
  • the original packet header is compared to the header of each packet in the set of potentially matching NAT-modified packets using the steps described below.
  • the network device monitor server determines whether the original packet is inbound or outbound. For inbound traffic, static NAT and dynamic NAT will modify the destination IP address. If the original packet is inbound, execution proceeds to step 902, where the unmodified IP header attributes describing the destination port (DstPort), source IP address (SrcIP), and source port (SrcPort) are compared to the original packet. For outbound traffic, static NAT and dynamic NAT will modify the source IP address.
  • DstPort destination port
  • SrcIP source IP address
  • SrcPort source port
  • step 903 the unmodified IP header attributes describing the source port (SrcPort), destination IP address (DstIP), and destination port (DstPort) are compared to the original packet.
  • SrcPort source port
  • DstIP destination IP address
  • DstPort destination port
  • Fig. 15b shows a flowchart for comparing packet header information when overloading NAT is used, which changes both the IP address and port number of entering packets.
  • the network device monitor server determines which direction the original packet is moving.
  • the network device modifies the destination IP address and port for inbound traffic and modifies the source IP address and port for outbound traffic.
  • the address attributes used to compare the original packet to potentially matching NAT-modified packets are the ones that remain unmodified by NAT.
  • inbound traffic is compared to the original packet by the source IP address (SrcIP), and source port (SrcPort) at step 904, and outbound traffic is compared to the original packet by the destination IP (DstIP) and destination port (DstPort) in step 905.
  • DstIP destination IP
  • DstPort destination port
  • Fig. 16 shows a flowchart of a deep compare process, where a set of NAT -modified packets potentially matching an original packet is further filtered through additional comparisons, and a final hash comparison is done to determine if any of the potentially matching packets actually match the original packet.
  • the process passes from the flowcharts of Figs. 15a and 15b to a deep compare at step 906.
  • the network device monitor server determines if the original packet is a TCP packet. If the packet is not a TCP packet, TCP comparison steps 1002 - 1005 are skipped and the network device monitor server proceeds to compare the payload size in step 1006.
  • step 1002 begins a comparison of TCP attributes in order to further narrow the set of potentially matching NAT- modified packets. In each comparison, finding the same value between the original packet and the NAT modified packets does not mean the two packets are the same, but finding different values indicates the unmatching packet should be removed from the set of potentially matching NAT modified packets.
  • Step 1003 compares the TCP sequence number
  • step 1004 compares the TCP acknowledge number
  • step 1005 compares the TCP checksum. A checksum is just a hash computed using identifying fields in the packet header. Execution then proceeds to step 1006 to compare the payload size. If the payload size is different between the original packet and any packets in the set of potentially matching NAT-modified packets, those packets are excluded from further comparison, narrowing down the possible choices for the final hash comparison of steps 1007 - 1011.
  • the network device monitor server iterates through each packet remaining in the set of NAT-modified packets potentially matching the original packet.
  • the original packet header is modified to match the packet header of the NAT-modified packet.
  • the checksum of the original packet is then recomputed in step 1009 based on the modified packet header.
  • the network device monitor server compares the recomputed original packet checksum to the checksum of the NAT-modified packet that provided the packet header information for modifying the original packet. If these packets have the same checksum, a matching packet has been found, and no alert is generated. If the checksums do not match, the network device monitor server moves to the next packet in step 1011 and repeats steps 1008 - 1010. When the network device monitor server fails to find a packet matching the original packet, an alert is generated.
  • steps 1007 - 1011 can be replaced with a comparison of a hash of the payload, as described above with reference to Fig. 10. In some cases, such as when the hash has already been computed for some or all of the potentially matching packets, skipping the checksum step and going straight to a hash comparison may be faster than doing the checksum first followed by a single hash comparison of the resulting match.
  • One of the advantages of the present invention is that the actual payload of packets does not need to be directly inspected. All the information required for detecting stealth network traffic is in the packet header or with payload metadata or a hash on the payload. This greatly reduces the amount of storage space required by the present invention, increases the speed with which a network capture report 105 can be transmitted and analyzed, and reduces overhead on the network and computing power required of the central processing server 104.
  • the alert can be as simple as a notification that stealth network traffic was found. It may also indicate which network device is responsible for the stealth network traffic.
  • discovering which network device caused the alert is trivial because the origin is naturally identified by the position of the tap or network capture device within the network. The information from the headers of these packets could be included in detailed information about the alert so that a qualified network manager can interpret the alert and decide how to address it.
  • the network device monitor server keeps a log of all network traffic captured, including packet payload. This allows the packet's payload to be analyzed to detect a possibly unknown malware threat or identify what data, if any, has been compromised.
  • One of ordinary skill in the art would recognize there are a variety of ways to issue an alert and a variety of levels of detail that an alert can include.
  • monitor server 102, 601, 602, 603, 702 described herein may be implemented either as a standalone physical unit dedicated to the tasks of the monitoring network activity described above, in hardware, firmware, or in software running on a general purpose server on the network. Monitor servers may also be integrated into the same system with the network capture device or central processing server described in the parent application.
  • monitor servers may also be integrated into the same system with the network capture device or central processing server described in the parent application.
  • block diagrams and flowchart illustrations depict methods, apparatuses (i.e., systems), and computer program products.
  • Any and all such functions can be implemented by computer program instructions; by special-purpose, hardware-based computer systems; by combinations of special purpose hardware and computer instructions; by combinations of general purpose hardware and computer instructions; and so on - any and all of which may be generally referred to herein as a "circuit,” "module,” or "system.”
  • each element in flowchart illustrations may depict a step, or group of steps, of a computer-implemented method. Further, each step may contain one or more sub-steps. For the purpose of illustration, these steps (as well as any and all other steps identified and described above) are presented in order. It will be understood that an embodiment can contain an alternate order of the steps adapted to a particular application of a technique disclosed herein. All such variations and modifications are intended to fall within the scope of this disclosure. The depiction and description of steps in any particular order is not intended to exclude embodiments having the steps in a different order, unless required by a particular application, explicitly stated, or otherwise clear from the context.
  • a computer program consists of a finite sequence of computational instructions or program instructions. It will be appreciated that a programmable apparatus (i.e., computing device) can receive such a computer program and, by processing the computational instructions thereof, produce a further technical effect.
  • a programmable apparatus i.e., computing device
  • a programmable apparatus includes one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, programmable devices, programmable gate arrays, programmable array logic, memory devices, application specific integrated circuits, or the like, which can be suitably employed or configured to process computer program instructions, execute computer logic, store computer data, and so on.
  • a computer can include any and all suitable combinations of at least one general purpose computer, special-purpose computer, programmable data processing apparatus, processor, processor architecture, and so on.
  • a computer can include a computer-readable storage medium and that this medium may be internal or external, removable and replaceable, or fixed. It will also be understood that a computer can include a Basic Input/Output System (BIOS), firmware, an operating system, a database, or the like that can include, interface with, or support the software and hardware described herein.
  • BIOS Basic Input/Output System
  • Embodiments of the system as described herein are not limited to applications involving conventional computer programs or programmable apparatuses that run them. It is contemplated, for example, that embodiments of the invention as claimed herein could include an optical computer, quantum computer, analog computer, or the like.
  • a computer program can be loaded onto a computer to produce a particular machine that can perform any and all of the depicted functions.
  • This particular machine provides a means for carrying out any and all of the depicted functions.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Computer program instructions can be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner.
  • the instructions stored in the computer-readable memory constitute an article of manufacture including computer-readable instructions for implementing any and all of the depicted functions.
  • a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
  • a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • computer program instructions may include computer executable code.
  • languages for expressing computer program instructions are possible, including without limitation C, C++, Java, JavaScript, assembly language, Lisp, and so on. Such languages may include assembly languages, hardware description languages, database programming languages, functional programming languages, imperative programming languages, and so on.
  • computer program instructions can be stored, compiled, or interpreted to run on a computer, a programmable data processing apparatus, a heterogeneous combination of processors or processor architectures, and so on.
  • a computer enables execution of computer program instructions including multiple programs or threads.
  • the multiple programs or threads may be processed more or less simultaneously to enhance utilization of the processor and to facilitate substantially simultaneous functions.
  • any and all methods, program codes, program instructions, and the like described herein may be implemented in one or more thread.
  • the thread can spawn other threads, which can themselves have assigned priorities associated with them.
  • a computer can process these threads based on priority or any other order based on instructions provided in the program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne de façon générale la détection d'activité malveillante en réseau émanant de dispositifs de réseau tels que des routeurs et des pare-feu. En particulier, certains modes de réalisation de la présente invention concernent la détection de logiciels malveillants furtifs sur un dispositif de réseau en comparant le trafic de réseau entrant et sortant pour découvrir des paquets émanant du dispositif de réseau et des paquets qui violent des règles de configuration. Lorsqu'il est combiné avec un serveur de surveillance du trafic de réseau configuré pour surveiller les comptes rendus de trafic de réseau réel et pour recevoir des comptes rendus de trafic de réseau connu en provenance d'ordinateurs hôtes, le système peut détecter le trafic de réseau furtif émanant à la fois des dispositifs de réseau et des systèmes informatiques hôtes.
PCT/US2015/036120 2014-07-21 2015-06-17 Identification de dispositifs de réseau infectés logiciels malveillants par surveillance du trafic WO2016014178A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US14/336,004 US10659478B2 (en) 2014-07-21 2014-07-21 Identifying stealth packets in network communications through use of packet headers
US14/336,004 2014-07-21
US14/635,761 US10313372B2 (en) 2015-03-02 2015-03-02 Identifying malware-infected network devices through traffic monitoring
US14/635,761 2015-03-02

Publications (1)

Publication Number Publication Date
WO2016014178A1 true WO2016014178A1 (fr) 2016-01-28

Family

ID=55163507

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/036120 WO2016014178A1 (fr) 2014-07-21 2015-06-17 Identification de dispositifs de réseau infectés logiciels malveillants par surveillance du trafic

Country Status (1)

Country Link
WO (1) WO2016014178A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10419467B2 (en) 2016-05-06 2019-09-17 SecuLore Solutions, LLC System, method, and apparatus for data loss prevention
CN110521179A (zh) * 2017-03-22 2019-11-29 赛门铁克公司 用于强制执行动态网络安全策略的系统和方法
WO2022143511A1 (fr) * 2020-12-31 2022-07-07 华为技术有限公司 Procédé d'identification de trafic malveillant et appareil associé

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090323703A1 (en) * 2005-12-30 2009-12-31 Andrea Bragagnini Method and System for Secure Communication Between a Public Network and a Local Network
US20100154059A1 (en) * 2008-12-11 2010-06-17 Kindsight Network based malware detection and reporting
US20110004876A1 (en) * 2009-07-01 2011-01-06 Riverbed Technology, Inc. Network Traffic Processing Pipeline for Virtual Machines in a Network Device
US20120117653A1 (en) * 2008-02-29 2012-05-10 Alcatel-Lucent Malware detection system and method
US8516586B1 (en) * 2011-09-20 2013-08-20 Trend Micro Incorporated Classification of unknown computer network traffic

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090323703A1 (en) * 2005-12-30 2009-12-31 Andrea Bragagnini Method and System for Secure Communication Between a Public Network and a Local Network
US20120117653A1 (en) * 2008-02-29 2012-05-10 Alcatel-Lucent Malware detection system and method
US20100154059A1 (en) * 2008-12-11 2010-06-17 Kindsight Network based malware detection and reporting
US20110004876A1 (en) * 2009-07-01 2011-01-06 Riverbed Technology, Inc. Network Traffic Processing Pipeline for Virtual Machines in a Network Device
US8516586B1 (en) * 2011-09-20 2013-08-20 Trend Micro Incorporated Classification of unknown computer network traffic

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10419467B2 (en) 2016-05-06 2019-09-17 SecuLore Solutions, LLC System, method, and apparatus for data loss prevention
CN110521179A (zh) * 2017-03-22 2019-11-29 赛门铁克公司 用于强制执行动态网络安全策略的系统和方法
WO2022143511A1 (fr) * 2020-12-31 2022-07-07 华为技术有限公司 Procédé d'identification de trafic malveillant et appareil associé

Similar Documents

Publication Publication Date Title
US10313372B2 (en) Identifying malware-infected network devices through traffic monitoring
US11277383B2 (en) Cloud-based intrusion prevention system
US20200259793A1 (en) Stream scanner for identifying signature matches
US20200177548A1 (en) Multi-tenant cloud-based firewall systems and methods
Özçelik et al. Software-defined edge defense against IoT-based DDoS
Habibi et al. Heimdall: Mitigating the internet of insecure things
US9544273B2 (en) Network traffic processing system
US8650287B2 (en) Local reputation to adjust sensitivity of behavioral detection system
US9407602B2 (en) Methods and apparatus for redirecting attacks on a network
US7735116B1 (en) System and method for unified threat management with a relational rules methodology
JP6634009B2 (ja) ハニーポートが有効なネットワークセキュリティ
US20220060498A1 (en) System and method for monitoring and securing communications networks and associated devices
US20070022474A1 (en) Portable firewall
US8898784B1 (en) Device for and method of computer intrusion anticipation, detection, and remediation
US11277428B2 (en) Identifying malware-infected network devices through traffic monitoring
US11930036B2 (en) Detecting attacks and quarantining malware infected devices
Scarfone et al. Intrusion detection and prevention systems
KR20090090641A (ko) 능동형 보안 감사 시스템
Hindy et al. A taxonomy of malicious traffic for intrusion detection systems
Venkatramulu et al. Various solutions for address resolution protocol spoofing attacks
Saad et al. A study on detecting ICMPv6 flooding attack based on IDS
WO2016014178A1 (fr) Identification de dispositifs de réseau infectés logiciels malveillants par surveillance du trafic
US9686311B2 (en) Interdicting undesired service
Khosravifar et al. An experience improving intrusion detection systems false alarm ratio by using honeypot
EP3133790B1 (fr) Procédé et appareil d'envoi de message

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15825200

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15825200

Country of ref document: EP

Kind code of ref document: A1