WO2018056895A1

WO2018056895A1 - Real-time packet reconstruction technology - rtpr

Info

Publication number: WO2018056895A1
Application number: PCT/SG2016/050464
Authority: WO
Inventors: Frankie CHAN KOK LIANG; Foo MOO TENG; Edgardo OSILLADA GONZALES II; Baterina ANNA VERONICA
Original assignee: Pte Ltd, Expert Team
Priority date: 2016-09-22
Filing date: 2016-09-22
Publication date: 2018-03-29

Abstract

The marketplace requires a breakthrough network packet forensics solutions for Internet Monitoring, Cyber Security and Intelligence, Cyber Crime Prevention and Investigation for Enterprises, Government and Internet Service Provider (ISP) networks. Real-Time Packet Reconstruction Technology (RTPR) is our invented mechanism in decoding and reconstructing the network packets in real-time (or near real-time) for various purpose for Cyber Security and Cyber Intelligence. RTPR provides real-time (or near real-time) network packet content decoding and reconstruction. Unlike others prior arts or available market solutions which only abstract metadata from the captured network packets, we do not abstract metadata, however decode and reconstruct the captured network packets back to its original content, regardless of traffic throughput. That means whatever the network packets passing through our system and processed by RTPR, the traffic will be reconstructed back. For example, if the traffic contains a webpage, the whole webpage will be reconstructed back in real-time (or near real-time) and this allows the relevant Administrator or Authority to visualize the webpage to decide the next course of action.

Description

DESCRIPTION

Real-Time Packet Reconstruction Technology - RTPR

Technical Field

Embodiments of the present invention generally relate to computer and digital processing systems for decoding and reconstructing of computer network packets in real-time (or near real-time).

Background Art

Deep Packet Inspection is a common technology to inspect on the content of the network packets and to classify them accordingly whether the content is clean or contains virus, malware, backdoor and others. However, many of today solutions or arts only inspect the network packet header and first few bytes of the packet payload and not the whole payload content itself. Real Time Packet Reconstruction Technology (RTPR) is designed with the intention to reconstruct the whole network packet content in real-time (or near real-time) in order to identify the threats contain within the network traffic flow. The threats may not come from virus, malware or backdoor but actual visible content such as an Email, Chat Message and Voice over VoIP calls that threaten the security of a person, organizations, group of people or even the entire nation or world (National Security). Technical Problem

There are many prior arts or available market solutions that provide real-time (or near real-time) network packet inspection, detection or prevention of security threats such as virus, malware, backdoor and others. There are also available solutions that provide data retention where raw data will be captured (from the intercepted network such as the enterprise networks or the Internet Service Provider networks) and stored into huge size storage (Tera Bytes) in raw or meta data format for a limited period of time, which usually range from weeks to months. Whenever an incident occurs (such as data leakage for Enterprises, riots caused by political activities, terrorism activities and others), the data will then be retrieved and abstracted accordingly to the specific time frame. Decoding and reconstruction of the data will then be applied manually to obtain the content from the raw data or metadata sources. It will be a time consuming and tedious process to dig out the data from a large pool of stored data and then decode and reconstruct those content to find out the series of events that lead to an incident and identify the culprit.

Solution to Problem

The Real-Time Packet Reconstruction (RTPR) is designed to handle and process multiple millions of network traffic flows simultaneously, few Mbps up to tenths Gbps of traffic throughput concurrently. This allows captured data immediately be decoded and reconstructed without delay and potential threats to be identified in real-time (or near real-time). What is retained in the system storage for longer period of time is the reconstructed data for further record and evidence retention purpose. The RTPR works on 64-bit Operating System (OS) where we include our own enhanced Linux based OS, Intelligence Reconstruction Gear OS (IRGO) and also hardware which can be any commodity server (1 U or 2U) or blade sever system. Summary of the Invention

RTPR provides real-time (or near real-time) network packet content decoding and reconstruction. Unlike others prior arts or available market solutions which only store raw data or abstract and store metadata from the captured network packets, we do store raw data or abstract metadata, however decode and reconstruct the captured network packets back to its original content, regardless of traffic throughput in real-time (or near real-time). That means whenever the network packets passing through our system and processed by RTPR, the traffic will immediately be reconstructed back to its original content view. For example, if the traffic contains a webpage, the whole webpage will be reconstructed back in realtime (or near real-time) and this allows the relevant administrator or authority to visualize the webpage to decide the next course of action. If the reconstructed data contains threats, then the threats can be immediately identify and mitigation process can then be carried out.

Advantageous Effects of Invention

Here is the list of advantages effects of the RTPR technology invention:

• Content of the data captured can be decoded and reconstructed in realtime (or near real-time). This allows threats to be discovered almost instantly and reduce the potential risk.

• RTPR provides the network administrator easier way to monitor the Internet traffic. Network users' Internet communication content can be reconstructed in real-time (or near real-time) with RTPR. This allows the management of the organization to understand network users' behavior from the Internet activities. Besides, if there is any dispute or data leakage from the network users, the management can easily trace and track the culprits with legitimate evidence. • Furthermore, through RTPR, Law Enforcement Agencies (LEA) such as Police, Military, Intelligence Agencies, National Security Agencies, Counter Terrorism Agencies, Commercial Crime Investigation Agencies and Government Ministries can have a more user friendly but professional platform to track down all illegal and criminal activities such as Online

Scam, Online Gambling and others over the Internet from Internet Service Provider networks in real-time (near real-time).

• With RTPR, there is no longer to have huge storage to retain the raw data traffic anymore. All captured data will be decoded and reconstructed in real-time (or near real-time). The retained data is the processed and indexed reconstructed data which ease off and quicken the process of searching into huge data stored.

Detailed Description of Drawings

The two diagrams will show the core engine, IRGO and the RTPR Technology. Refer to detail description of Drawings below.

Fig. 1 shows the operating system core engine, known as Intelligence Reconstruction Gear OS (IRGO) which is enhanced from a Linux operating system.

The IRGO core engine is designed based on Linux Kernel Architecture with optimized performance. The IRGO core engine includes two major parts which are User Space and Kernel Space. IRGO core engine User Space consists of 001 - Applications/Tools, which includes our invented RTPR technology, DPI Filtering and even can work with other 3^rd party applications like Malware Detection, DDOS Detection and others. IRGO core engine Kernel Space consists of three parts: Components, Software Support and Hardware Support. The five major Components are: 002 - Process Management, 003 - Memory Management, 004 - File Systems + Databases, 005 - Device Drivers and 006 - Network. The five functionalities connecting the Components and Software + Hardware Support are: Multitasking, Virtual Memory + SWAP, File Directories, Device Access Terminals and Network Functionalities. The Major Software and Hardware Supports are: 007 - Scheduler Architecture - Specific Core, 008 - Memory Manager, 009 - File Systems Types - Ext4 + SQL, 010 - Block Devices

- 01 1 - Character Devices, 012 - Network Protocols and 013 - Network Drivers. Fig. 2 shows the overall processes of the invented Real-Time Packet Reconstruction Technology (RTPR). It depicts the action from packet capture (packet sources), packet processing till the storing of reconstruction data in the respective database and file systems. Packet is captured from a source 100 - Packet Source either live from an interface or from a capture dump (PCAP format). Packet is then passed to a 1 01

- Dissector for stripping headers (up to TCP/UDP layer) and extracting the info such as MAC address, IP address, port. Packet, together with header information, is passed to a 1 02 - Flow Manager for grouping packets belonging to the same "flow" together. 103 - Protocol Checkers try to identify the protocol used for a group. There are multiple protocol checkers, one for each protocol - for example: HTTP, IMAP, POP. 104 - Protocol Decoders extract the application-layer data. There are multiple protocol decoders, one for each protocol - for example: HTTP, IMAP, POP. The application data is queued for further processing. A separate thread checks the queue for available data. The data is sent to the appropriate module (for further decoding of the application data, if needed; or direct to the DB if no further decoding needed). If the data requires further decoding (for example: for data of services that run on top of another protocol), an application data decoder will extract the necessary information. If the data produced by a protocol decoder (or a set of protocol decoders) needs to undergo further decoding, it goes through a 105 - Application Data Decoder (or a set of application data decoders). The "final" set of data is saved to the 106 - Data Store/Database. Saving is done in bulk/batches.

Fig. 2 shows the overview of typical implementation of RTPR and respective systems. RTPR for real-time (or near real-time) network packet reconstruction will be implemented at the front end capture system, known as 3i system. Reconstructed data will be kept in 3i-RS system for a longer period of time with customizable storage size. 3i-CS system is a centralized management system to manage multiple 3i and 3i-RS systems at one or multiple locations. Each system has a web application with Graphical User Interface (GUI). It includes a management GUI and a set of web services. The management GUI is for the end user - for system administration and data viewing. The web services are for allowing the systems to communicate or exchange information with one another.

Claims

CLAIMS Real-Time Packet Reconstruction Technology - RTPR Claims

[Claim 1 ] RTRP technology is a methodology for reconstructing network packet in real-time (or near real-time) consist of the components: Capture

Module, Dissector, Flow Manager, Protocol Checkers, Protocol Decoder (also known as Parser), Application Data Decoder and DB Module.

[Claim 2 ] Network packet is captured from a source via Capture Module - either live from a network interface (through tapping or mirrored port of a managed switch) or from a capture dump (PCAP format).

[Claim 3 ] Network packet is then passed to a Dissector for stripping off the network headers (up to TCP/UDP layer) and extracting the information including MAC address, IP address and port.

[Claim 4 ] Network packet, together with header information, is passed to Flow

Manager for grouping packets belonging to the same "flow" together.

[Claim 5 ] Protocol Checkers try to identify the protocol used for a group. There are multiple protocol checkers, one for each protocol - for example: HTTP, IMAP, POP, SMTP, FTP, P2P, VOIP and others.

[Claim 6 ] Protocol Decoders (also known as Parser) extract the application- layer data. There are multiple protocol decoders, one for each protocol - for example: HTTP, IMAP, POP, SMTP, FTP, P2P, VOIP and others.

[Claim 7 ] The application data is then queued for further processing. A separate thread checks the queue for available data. The data is sent to the appropriate module (for further decoding of the application data, if needed; or direct to the Database (DB) if no further decoding needed). If the data requires further decoding such as for data of services that run on top of another protocol such as Facebook - Social Media Application which run on top of HTTP/HTTPS protocol), an application data decoder will extract the necessary information.

[Claim 8 ] If the data produced by a protocol decoder (or a set of protocol decoders) needs to undergo further decoding, it goes through an Application Data Decoder (or a set of application data decoders). [Claim 9 ] The "final" set of data is saved to the data store, in respective

Database (DB) and file system. Saving is done in bulk/batches.