Improving Response capabilities to Internet Emergency through a
High Performance Network Resource Platform
Ni Zhang, Binxing Fang, YaoWang
Institute of Computing Technology
Chinese Academy of Sciences
NO. 6, South Road, Kexueyuan, Zhongguancun, Beijing
P.R.China
Abstract: - We propose a new design for supporting Internet emergency services effectively, which we call the query-driven and distributed network resource platform (QDNR). We improve response capabilities of network security department to Internet emergency by: 1) supporting fast and batch queries service and providing queried-driven mechanism to make it possible for network security department to have an adequate response to illegitimate attacks and reduce the loss of attacks, which is also different from other public network resources platforms now; and 2) proposing a novel redundancy-avoided mechanism for improving the performance of information storing and querying. We evaluate the performance of QDNR through a series of experiments in real condition. Results show that QDNR exhibit higher performance than traditional network resource platforms in network security field.
Key-Words: - emergency, response capabilities, queried-driven, redundancy-avoided，network security
1 Introduction
With the rapid development of the network technology, Internet has become one of the most popular applications, which allow users to access information and resources from all over the world. Unfortunately, as a result of this increased popularity and usefulness, the Internet contains both interesting targets and enough malicious and ignorant users. Recent studies have shown a surpringly high number of emergencies such as the Code Red and Nimda occurring around the clock throughout the World. According to [1], China Computer Network Emergency Processing Center had dealt with 10873 illegitimate attacks in 2003, which was a great loss to rapid development of Internet.
How can we monitor and control the spread of worms accurately? How can we find the source of an attack in a timely fashion? To address these challenges, in this paper, we present QDNR, an distributed infrastructure that provide better IP information query service to meet the demand in network security field.
QDNR provide a new solution to control malicious attack effectively. QDNR works as a network resources database by collecting and processing IP address in CHINA through multiple ways. When Internet emergency happens, by submitting the queries of suspicious IP addresses to the interface provided by QDNR, officers in network security department can get related descriptive information, such as the organization the IP addresses belong to, geographical information the IP addresses locate and then they can describe epidemic situation accurately and find out the troublemakers or victims in time. Thus Secure Institute can control or cut off the spread quickly.
The remainder of the paper is organized as follows. We provide an overview of related network in Section 2. Architecture of QDNR appears in section 3. From section 4 to section 6, we will discuss some technologies to improve query performance in our design. Section 7 presents results of experiments. We conclude in section 8.
2 Background and Related work
Network resources platform provides a basic information service of IP address. Users can access these data through public interface, obtaining attribute information of given host, therefore acquiring accurate description to the target host.
Before connecting to the internet, the organizations must apply for IP address to some public platform, filling in the basic information about their network. At present, there are mainly three public network resource platforms in the world. ARIN [2] is mainly responsible for the business of North America area. IP Address of the Asian- Pacific area is allocated by APNIC [3]. As for RIPE [4], it is responsible for the business of Europe.
The importance of such resource platform has been recognized by both the commercial and research world. Some work has been done to make full use of these resources, e. g [5]. However, for some reason these work doesn’t apply this invaluable information to network security field. Maybe there are some main factors which limit their function.
● Bad real-time character: Network resource database, such as APNIC do provide related records such as who administrate the IP Address. However, the information can be out of date and does not reflect the present allocation of network resources. [5]
● Bad query service: Traditional network resource platforms don’t take response capabilities of network security institute into account. They only provide limited and delayed singular query service in their homepages.
● Redundant data inside the platform: Information in traditional platforms is stored randomly and redundantly without a uniform format which will bring the problem of query ambiguity. So it is difficult for user to make a choice from redundant information.
Considering the limits of traditional network resource platforms and demands of network security department, we think an advanced and practical network platform should be fault tolerance and provide high quality service for specific users.
Thus we design a new network resource platform--QDNR, which is applied in network security field to address the challenge of Internet emergencies.
3 Distributed and fault-tolerant architecture of QDNR
In this section, we describe the architecture of QDNR.
Fig.1 Distributed architecture of QDNR
QDNR is based on server–client architecture, which is shown in Fig.1, Information in our system is distributed. Every client collects a number of local IP data (which discussed in section 4.1.1) in their area and uploads data to the servers. Two servers, which receive all resources respectively, keep company with each other. The main server broadcasts current configuration information to other nodes and the associate server works as backup for main server. When main server breaks down, associate server can replace it promptly. At worst, when both two servers lost their data, they can collect backup data in other clients easily.
This architecture can maintain fault tolerance in the face of network faults and provide continuous service for users.
4 Better query services
Further, we will detail some technologies to improve performance in our design.
4.1 Fast query
That’s to say, in a query transaction, QDNR should return related descriptive information as quickly as it can. To provide fast query service, our platform should achieve these goals. Firstly, QDNR should design a good data collect mechanism to guarantee that platform can provide users as much as accurate information in time. Secondly, QDNR should keep information in local database, which guarantees that users’ request can hit in platform and avoid real-time accessing to other platforms.
4.1.1 Data collection
Now QDNR mainly adopts these data collection ways as followed:
(1) Local IP data:
The collection work of the local IP data is completed on the client ends. The administrators who maintain these client nodes make a long-term contact and cooperation with ISPs and network resource entities in this area, obtaining their IP addresses and uploading the data to IP information table of servers. When allocation of these resources changed, client ends can update resources in the database in time. Obviously, the local IP data coming from their owners directly, which represent the last allocation information of IP addresses, is real-time, accurate, and more credible than WHOIS data in other platforms. The local IP data kept in IP information table, is the most important resource in QDNR.
(2) WHOIS data: However, the local IP data is the private information of ISPs or network entities. For some commercial reasons, network entities are unwilling to announce the resource information of their network. And the collection of local IP data is a gradual course. So QDNR platform collects WHOIS data periodically from other network resources platforms such as APNIC, as the supplements to the local IP data. Because WHOIS data is kept in big granularity, the credibility of this way is relatively low.
(3) Users-defined data: Namely, the information is obtained from any ways. For example, QDNR can get a large number of injured hosts IP address from worms attacking incident. Users-defining data is kept in IP information table.
4.1.2 Localization of information
In a query transaction, when local IP data doesn’t hit, QDNR usually falls back on other WHOIS data. Because accessing to remote WHOIS platform in real-time way wastes a lot of time, we get WHOIS data and keep them in QDNR in advance, updating them periodically. As a result, it can improve query performance of the QDNR.
4.2 Batch query
QDNR provide batch query service for users without the limit of the query quantity. Authorized users can access the information in homepages freely. QDNR also provides file interface which accepts file input with extension name “.exl” and “.txt”.
5 Query-driven and circular feedback mechanism
In the design of QDNR, we adopt Query-driven and circular feedback mechanism, which works as followed:
(1) User submits the queries through interface.
(2) Query module searches related data tables in turn until finding the right record.
(3) QDNR provides location information to security department.
(4) If the query does not hit, QDNR will query other large scale platforms periodically and then keep the return information.
(5) After controlling the emergency, security department returns feedback information to QDNR. QDNR makes full use of real data to testify and update data in database.
From steps (4) to (5), through users' query, QDNR can make full use of not hit data and feedback data to enrich information capacity. As a result, QDNR and Security department can make progress each other by the mechanism of circular feedback, which is a process of getting balance and development dynamically.
Fig.2 Query-driven and circular feedback mechanism
6 Redundancy-avoid mechanism
6.1 IP information table
IP information table plays a important role in QDNR, which keeps the last allocation information of IP addresses, including detailed description such as geographical location, organization these IP addresses belong to, etc. This table supports IP data from multiple ways, so lots of overlapped records stored in the database. These redundant data has a shortcoming: Query ambiguity, that is, when user submits one request, the database will return many records, makeing it difficult for user to make a choice. So we will propose a novel mechanism to keep information low redundancy and improve QDNR’s query performance.
6.2 The policy of temporary table
However, processing redundant data when they are imported to servers will take up a large number of CPU time and make impact on other modules’ work. So in database design, we build a temporary table for IP information table (we call it formal table in this paper). The server keeps the new uploading data in temporary table firstly, and then processes the records both in temporary table and in formal table at the same time. At last, the server keeps processed data in the formal table and deletes records in temp table according to time stamp.
Although the real-time character degrades to some extent, it can effectively balance the load in QDNR and keep information in a compact and efficient storage.
6.3 Redundancy-avoid mechanism
At first, we introduce some definitions as followed.
Definition 1: We assume that R = [s, e, A] is a record in IP information table, s, e representing the first and the last IP address of this record, and A representing description information of this IP segment.
Definition 2: We assume that record stored in formal table is represented by [s1, e1, A1], while data in corresponding temporary table is represented by [s2, e2, A2].
In order to make it easy for IP address compare, in this paper we use integer to represent IP address.
The redundancy-avoid mechanism is followed:
(a) If two compared records in formal table and in temporary table are collected from the same way, that is, s_id1=s_id2:
As Fig.3 (a) shows, if the address space of record in temporary table includes that of record in formal table, former record replaces the latter record directly.
As Fig.3 (b) shows, if the address space of record in temporary table is included in that of the formal table , we split the record in formal table into three parts , modifying addresses of the first and the last parts, keeping its original attribute and replacing the second part by record in temporary table.
Fig.3 Redundancy-avoid mechanism of IP information table
As Fig.3 (c), (d) shows, if the address spaces of records in temporary table and formal table overlap partly, we use former record replace overlay part and keep other part of record in formal table intact.
b) If two records collected by different ways with their address spaces overlap, QDNR refers these conflict records to users to verify them.
7 The evaluation
We evaluate our implementation and measure the performance of QDNR using several experiments.
7.1 Evaluation Methodology:
We begin with a short description of our experimental methodology. Our platform is consisted of a series of distributed database nodes and interface nodes. The client database only keeps own data from local interface node and transfers the new coming data to the two server databases and two server databases both receive the data from client databases. Interface nodes are distributed both in server and client ends. They are used for importing IP address to corresponding databases and providing query interface for user.
All the database nodes are deployed by dual Pentium III 1-GHz, 4GB RAM and interface nodes deployed by Pentium IV 2.4GHz, 512M RAM.
7.2 Query performance:
We use host IPs got in breaking out of worms in March 2003 as test data. We make experiments twice independently. At first time, we query the remote WHOIS database of APNIC(whois.apnic.net:43). At second time, we submit IPs to QDNR. We query 50,100,200,350,500 records in each test and write down the time costs.
Because accessing to remote WHOIS databases wastes a lot of time, which has a great impact on query performance. As can been seen from fig.4 (a), when 500 IP addresses inquired, one should not receive the result until more than 600 seconds.
While QDNR keeps information in local database, which guarantees that users' request can hit in platform and avoid real-time accessing to other platforms. As shown by fig.4 (b), QDNR can deal with 500 IP addresses and return results in 15 seconds. The query performance is vital to network security department, when the emergency happens, which can improve response capabilities and cut off the spread quickly.