I n t e r ne t
I n f r a s t r u c t u re
Rev i e w
Infrastructure Security

Large-Scale DDoS Attacks in the United Statesand South Korea

Messaging Technology

How Do We Discourage Asia from Continuing
to be a Source of Spam?

Cloud Computing Technology
Live Migration of Guest Computers Using
the NEMO BS Mobility Function

Service Infrastructure

The Design and Implementation of the NHN

Next Generation Service Infrastructure Using
Virtualization Technology andRemote Data Centers

Vol.5

November2009

Table of Contents

I n t e r ne t I n f r a s t r u c t u re Rev i e w

Vo l.5

November 2009

Executive Summary ———————————————————— 3

1. Infrastructure Security ———————————————— 4
1.1
1.2
1.3

Introduction ———————————————————————— 4
Incident Summary ———————————————————— 4
Incident Survey — ———————————————————— 6

1.3.1

DDoS Attacks — ——————————————————————— 6

1.3.3

SQL Injection Attacks ————————————————————— 10

1.3.2

1.4

Malware Activities ——————————————————————— 7

Focused Research ———————————————————— 11

1.4.1

DDoS Attacks in the United States and South Korea — ————— 11

1.4.3

Randomly Arriving SIP Packets — ——————————————— 16

1.4.2

1.5

TCP Vulnerability (Sockstress) ————————————————— 14

Conclusion — ——————————————————————— 17

2. Messaging Technology ——————————————— 18
2.1
2.2

Introduction ———————————————————————— 18
Spam Trends — —————————————————————— 18

2.2.1

Spam Ratio Trends — ————————————————————— 19

2.2.3

International Anti-Spam Activities — —————————————— 21

2.2.2

2.3

2.3.1

2.4

Sources of Spam ——————————————————————— 19

Trends in Email Technologies — ———————————— 22

Adoption of Sender-Authentication Technologies ———————— 22

Conclusion — ——————————————————————— 23

3. Cloud Computing Technology —————————— 24
3.1
3.2
3.3
3.4
3.5
3.6
3.7

Background ———————————————————————— 24
Live Migration Issues —————————————————— 24
Overview of NEMO BS — ———————————————— 25
Design ——————————————————————————— 26
Verification Tests ————————————————————— 27
Evaluation and Issues — ———————————————— 28
Consideration — ————————————————————— 28

3.7.1

Network Storage Issues ———————————————————— 28

3.8

Conclusion — ——————————————————————— 29

3.7.2

Usability Issues ———————————————————————— 29

4. Service Infrastructure — —————————————— 30
4.1
4.2

Background to Adoption of NHN — —————————— 30
A Design Plan Optimized Remote Data Center ——— 31

4.2.1

Storage Failure Rates at IIJ — ————————————————— 31

4.2.3

Network Device Failure Rates at IIJ — ————————————— 32

4.2.2

4.3

4.3.1

Server Failure Rates at IIJ ——————————————————— 31

NHN Configuration — —————————————————— 32

Adoption of iSCSI-based IP SAN — —————————————— 33

4.3.2	Implementing a Diskless Server Combining iSCSI Storage andEnergy-Saving Servers — ——————————————————— 33

4.3.3	Implementing a Virtual Network That Requires

4.4

No Cabling Changes Using VLAN — —————————————— 34

Results of Adoption of NHN — ————————————— 34

Internet Topics: About the anti-Malware

engineering WorkShop 2009— ——————————— 35n To download the latest issue of the Internet Infrastructure Review, please visit (http://www.iij.ad.jp/en/development/iir/).
2

On August 17, 2009, the Ministry of Internal Affairs and Communications published the “International Comparative
Evaluation Report on ICT Platform in Japan.” According to this report, Japan was ranked overall as the top country
out of 24 evaluated. A closer look reveals that Japan ranked at the top for broadband affordability, optical fiber
installations, and broadband speeds. Indeed, Japan has developed a technological infrastructure that supports highconnections speeds at low costs.
In regard to indices representing the advancement of social infrastructure, however, Japan ranked only 11th withrespect to the number of Internet hosts and 13th with respect to ICT investment. This leads one to conclude that,
despite having established an infrastructure for the network, Japan is lagging in server infrastructure as well as
service development and related ICT investment which need well-deployed server infrastructure. Cloud computing
infrastructure and related business services leveraging Japan’s cheap, fast networks must be developed before one
can say that Japan’s ICT infrastructure and competitive ability are world-class.
As exemplified in some of the cloud computing models introduced last year and throughout this year, the Internet
is an amalgamation of networking and computing. A wide variety of elements come together to comprise theInfrastructure of the Internet, which operates as a complex system built upon many different layers. Monitoring andanalysis of the behavior of these various elements and layers—as well as continued technological development inpursuit of new usage models—is an indispensable part of ensuring the development of ICT infrastructure and stable
operations of this complex system.
This whitepaper discusses the various monitoring and analysis activities in which IIJ engages to contribute to
the perfection and growth of Internet infrastructure. We also offer information related to new and developing
technologies.
Addressing Internet security and safety, we will report statistics and analyses of security incidents observed for thethree months from July 1 through September 30, 2009 in the “Infrastructural Security” section. Our observations andanalyses on DDoS attacks targeted multiple websites in the United States and South Korea, TCP vulnerabilities, andattacks on VoIP services exploiting SIP are also reported as focused researches on issues observed or revealed
during this period. Under the heading of “messaging technology,” we will report on our analysis of the state of spam,
and activities related to the adoption and trends in the advancement of sender authentication technologies.
Addressing technological development, we will offer overall description about “NHN”, project to migrate IIJ service
infrastructure to the cloud environment. We will also address experiments and verification test results regarding
our work to adapt Mobile IP technologies for migrating guest computers in a server virtualization environment on a
network basis.
IIJ continues to offer solutions for the stable, secure, and innovative use of the Internet as an infrastructure supporting
corporate activities. This whitepaper is one example of how we provide timely updates and information to ourclients.

Author:Toshiya Asaba
Executive vice president. Member of the WIDE Project. Mr. Asaba joined IIJ in its inaugural year of 1992, becoming involved in backbone construction,route control, and interconnectivity with domestic and foreign ISPs. Asaba was named IIJ director in 1999, and as executive vice president in charge oftechnical development in 2004. Mr. Asaba founded the IIJ Innovation Institute Inc. in June 2008, and he serves concurrently as president and CEO of thatorganization.

Executive Summary

Executive Summary

Infrastructure Security

1. Infrastructure Security

Large-Scale DDoS Attacks in the United States and South Korea
In this report, we will report on incidents to which IIJ responded between July and September 2009.

At the same time, we will also cite the details behind large-scale DDoS attacks targeting Web servers
in the United States and South Korea, TCP vulnerabilities announced by CERT-FI,
and the mechanism behind silent phone calls caused by SIP packets.

1.1 Introduction
This whitepaper summarizes incidents to which IIJ responded, based on general information obtained by IIJ itself related tothe stable operation of the Internet, information from observations of incidents, information acquired through our services,
and information obtained from companies and organizations with which IIJ has cooperative relationships. This volume covers
the period of time from July 1 through September 30, 2009. A multiple number of Web servers in the United States and South
Korea were subject to large-scale DDoS attacks during this period. A series of vulnerabilities related to Web browsers werealso discovered during this time, and reports cited a vulnerability in DNS servers and other servers used frequently for theInternet. Additionally, a TCP vulnerability that affects many implementations was announced. Besides these announcements

and incidents, there were several incidents that resulted in direct financial damages, including cases of fake security softwareand extortion in connection with DDoS attacks. As seen above, the Internet continues to experience many security-related
incidents.

1.2 Incident Summary
Here, we discuss the IIJ handling and response to incidents that occurred between July 1 and September 30, 2009. Figure 1
shows the distribution of incidents handled during this period.*1
Other 23.4%

Vulnerabilities
40.3%

Political and Social
Situation 5.1%

History 9.1%

Security Incidents 22.1%

Figure 1: Incident Ratio by Category (July 1 to September 30, 2009)*1

Incidents discussed in this whitepaper are categorized as vulnerabilities, political and social situation, history, security incident and other.

Vulnerabilities: Responses to vulnerabilities associated with network equipment, server equipment or software used over the Internet, or used commonly inuser environments.

Political and Social Situations: Responses to incidents related to domestic and foreign circumstances and international events such as international
conferences attended by VIPs and attacks originating in international disputes.

History: Historically significant dates; warning/alarms, detection of incidents, measures taken in response, etc., related to an attack in connection with a past historical fact.

Security Incidents: Wide propagation of network worms and other malware; DDoS attacks against certain websites. Unexpected incidents and related response.
Other: Those incidents not directly associated with security problems, including highly concentrated traffic associated with a notable event.
Vol.5

November 20094

During this period, vulnerabilities were fixed in user applications such as Microsoft’s Internet Explorer*2, SMB2.0*3, and Visual
Studio Active Template Library*4. Many vulnerabilities were also corrected related to Web browsers, including vulnerabilities in

ActiveX killbit*5, JScript*6, Adobe Flash Player and Adobe Acrobat Reader*7, and Apple QuickTime*8.

In addition to the foregoing, vulnerabilities were discovered that affect the stability of BIND9*9, Squid*10 and other software

utilized frequently on servers. A Cisco router BGP vulnerability*11 was corrected, and a regular update for IOS was released toaddress several vulnerabilities during the period under study*12. A vulnerability related to TCP was publicly announced, which
affected a large number of implementations. See “1.4.2 TCP Vulnerability (Sockstress)” for more about this TCP vulnerability.
■ Political and Social Situations

IIJ pays close attention to various political and social situations related to international affairs and current events. During theperiod under study, Japan observed the 45th House of Representatives general election, the inauguration of the Consumer
Affairs Agency, and other political events. However, IIJ noted no related Internet attacks.
■ History

The period in question included several historically significant days, including the observance of the end of World War II andthe observance of the end of the Pacific War in Japan. In the past, historically motivated DDoS attacks and website alterations
have occurred during this time of the year, and IIJ paid particular attention to political and social situations. However, no directly
related attacks targeting IIJ facilities or customer networks were detected.
■ Security Incidents

Unanticipated security incidents not related to political or social situations occurred in the form of multiple large-scale DDoS

attacks against web servers in the United States and Republic of Korea (South Korea) during the first part of July. See “1.4.1
DDoS Attacks in the United States and South Korea” for more related to these incidents. Additionally, attacks on P2P filesharing networks from a cloud environment*13 and a DDoS attack against Twitter*14 occurred. In August, a DDoS attack wasaccompanied by a demand for money, euphemistically called a cost of measures*15.

*2

Microsoft Security Bulletin MS09-034 – Critical: Cumulative Security Update for Internet Explorer (972260) (http://www.microsoft.com/ technet/security/*3

Microsoft Security Bulletin MS09-050 – Critical: Vulnerabilities in SMBv2 Could Allow Remote Code Execution (975517) (http://www.microsoft.com/japan/

*4

*5
*6
*7
*8
*9
*10
*11
*12
*13

*14

*15

Vol.5

bulletin/ms09-034.mspx).

security/Bulletin/MS09-050.mspx).

Microsoft Security Bulletin MS09-035 – Moderate: Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution (969706)(http://www.microsoft.com/technet/security/bulletin/ms09-035.mspx) and Security Advisory for Adobe Flash Player APSA09-04 (http://www.adobe.com/
support/security/advisories/apsa09-04.html).

Microsoft Security Bulletin MS09-032 – Critical: Cumulative Security Update of ActiveX Kill Bits (973346) (http://www.microsoft.com/ technet/security/bulletin/MS09-032.mspx).

Microsoft Security Bulletin MS09-045 – Critical: Vulnerability in JScript Scripting Engine Could Allow Remote Code Execution (971961) (http://www.microsoft.
com/ technet/security/bulletin/ms09-045.mspx).

Security advisory for Adobe Reader, Acrobat and Flash Player APSA09-03 (http://www.adobe.com/support/security/advisories/apsa09-03.html). Security
updates available for Adobe Flash Player, Adobe Reader and Acrobat APSB09-10 (http://www.adobe.com/support/security/bulletins/apsb09-10.html).
About the security content of QuickTime 7.6.4 (http://support.apple.com/kb/HT3859).

BIND Dynamic Update DoS (https://www.isc.org/node/474). This vulnerability relates to a BIND server which holds zone information as a primary server. Even
servers that provide only cache functions still frequently have zone information such as localhost, and need to be patched.
Squid Proxy Cache Security Update Advisory SQUID-2009:2 (http://www.squid-cache.org/Advisories/SQUID-2009_2.txt).

Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities (http://www.cisco.com/warp/
public/707/cisco-sa-20090729-bgp.shtml).

Cisco Security Advisory: Summary of Cisco IOS Software Bundled Advisories, September 23, 2009 (http://www.cisco.com/warp/public/707/cisco-sa20090923-bundle.shtml).

A cNotes article reported this incident. Attacks on Share P2P networks utilizing Amazon Web Service (http://jvnrss.ise.chuo-u.ac.jp/csn/index.cgi?p=Amazo
n+Web+Service%A4%F2%CD%F8%CD%D1%A4%B7%A4%BFShare%A5%CD%A5%C3%A5%C8%A5%EF%A1%BC%A5%AF%A4%D8%A4%CE%B
9%B6%B7%E2)(in Japanese).

Twitter’s tweet discussing the status of ongoing denial-of-service attacks (http://status.twitter.com/post/157191978/ongoing-denial-of-service-attack). The
Arbor Networks blog detailed the decrease in traffic volume “Where Did All the Tweets Go?” (http://asert.arbornetworks.com/2009/08/where-did-all-thetweets-go/)See the following article from Trend Micro regarding similar incidents “Botnet Extortion Attempts Extend to Japan (DDoS Attacks)” (http://blog.trendmicro.
co.jp/archives/1385)(in Japanese).
November 20095

Infrastructure Security■ Vulnerabilities

Infrastructure Security■ Other

As far as incidents not directly related to security, several international undersea cables were damaged by a typhoon in

Taiwan, affecting communications in and out of the area*16. A number of anti-virus software firms released 2010 updates, withconcurrent releases of counterfeit software nearly indistinguishable from these programs*17. Similarly, as Microsoft released its

free Microsoft Security Essentials*18 anti-virus tool during the period under study, fake security software (scareware) began toappear in search engine results, inducing unsuspecting users to click through*19.

1.3 Incident Survey
Of those incidents occurring on the Internet, IIJ focuses on those types of incidents that have infrastructure-wide effects,
continually conducting research and engaging in countermeasures. In this section, we provide a summary of our survey andanalysis results related to the circumstances of DDoS attacks, malware infections over networks, and SQL injections on Web
servers.

1.3.1 DDoS Attacks

Today, DDoS attacks on corporate servers are almost a daily occurrence. The methods involved in DDoS attacks vary widely.
Generally, however, these attacks are not the type that utilize advanced knowledge such as that of vulnerabilities, but rather
cause large volumes of unnecessary traffic to overwhelm network bandwidth or server processes for the purpose of hindering

services. Figure 2 shows the circumstances of DDoS attacks handled by the IIJ DDoS Defense Service between July 1 and
September 30, 2009.

This information shows traffic anomalies judged to be attacks based on IIJ DDoS Defense Service standards. IIJ also responds
to other DDoS attacks, but these incidents are excluded from the figure due to the difficulty in accurately ascertaining the factsof each situation.
(No. of Attacks)■Compound Attacks■Bandwidth Attacks■Server Attacks

16
14
12
10
8
6
4
2
0
2009.7.1

2009.8.1

2009.9.1(Date)

Figure 2: DDoS Attacks

2009.9.1 1
2009.8.1 0
0
0
date
TCP
UDP/ICMPHYBRID2009.9.2 2
2009.8.2
000
2009.7.1 0
01
2009.9.3 2
2009.8.3 2
00
2009.7.2 1
00
2009.9.4 1
2009.8.4
1
00
2009.7.3 1
00
2009.9.5 1
2009.8.5 2
00
2009.7.4 0
00
2009.9.6 2
2009.8.6
1
0
1
2009.7.5 2
00
2009.9.7 4
2009.8.7 2
00
2009.7.6 0
00
2009.9.8 1
2009.8.8
6
0
2
2009.7.7 1
00
2009.9.9 0
2009.8.9 14
002009.7.8 0
00
2009.9.10 1
2009.8.10
11
00
2009.7.90 include the0 following from NetworkWorld. “Asian undersea cable disruption slows Internet access” (http://www.networkworld.com/*16
Reports0about this incident
2009.9.11 3
2009.8.11 13
0
2
2009.7.10
300news/2009/081209-asian-undersea-cable-disruption-slows.html).
2009.9.12 1
2009.8.12
13
0
1
*17
Blog entry
accurately imitating Symantec products. Symantec Security Blogs: Nort “what” AV? (http://www.symantec.com/
2009.7.11
1 regarding 0counterfeit software0
2009.9.13 3
2009.8.13 100connect/blogs/nort-what-av).
2009.7.12
000
2009.9.14 4
2009.8.14
100*18Microsoft(http://www.microsoft.com/security_essentials/).
2009.7.13
3 Security Essentials
002009.9.15 4
0
0
0
*19
IIJ has confirmed
that0links leading 0
to fake software have ranked high2009.8.15
in English environment.
2009.7.14
2
2009.9.16 4
2009.8.16
000
2009.7.15 0002009.9.17 3
2009.8.17 2
002009.7.16 2
002009.9.18 2
Vol.5 November 20096
2009.8.18
100
2009.7.17 1
01
2009.9.19 1
2009.8.19 1
002009.7.18 0002009.9.20 0
2009.8.20
100
2009.7.19 0002009.9.21 3
2009.8.21 3
01
2009.7.20 0002009.9.22 0
2009.8.22
000
2009.7.21 001
2009.9.23 1
2009.8.23 0
0
0

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

0
0
0
0
1
0
0
0
0
0
0
0
0
1
0
0
0
6
0
0
0
0
0

(bandwidth and server performance) will largely determine the degree of impact. Figure 2 categorizes DDoS attacks into three
types: attacks on bandwidth capacity*20, attacks on servers*21, and compound attacks (several types of attacks on a single

target conducted at the same time).

During the three months under study, IIJ dealt with 192 DDoS attacks. This averages to 2.08 attacks per day, representing an

increase in the average daily number of attacks compared to our prior whitepaper. Considering the fact that a multiple numberof attacks occurring between August 9 and August 12 targeted a certain website for a lengthy period, the overall trend did nototherwise vary significantly from that discussed in our prior whitepaper.

Bandwidth capacity attacks accounted for 0% of all incidents. Server attacks accounted for 87% of all incidents, and compound

attacks accounted for the remaining 13%. The largest attack observed during the period under study was a compound attack

that tied up 566Mbps of bandwidth using 140,000pps packets. Of all attacks, 80% ended within 30 minutes of commencement,
while 19% lasted anywhere from 30 minutes to up to 24 hours. During the time period under study, IIJ noted one attack thatlasted for 94 hours and 30 minutes (approximately four days).

In most cases, we observed an extremely large number of IP addresses, whether domestic or foreign. We believe this isaccounted for by the use of IP spoofing*22 and botnet*23 usage as the method for conducting DDoS attacks.

1.3.2 Malware Activities

Here, we will discuss the results of the observations of the Malware Investigation Task Force (MITF)*24, a malware activity

observation project operated by IIJ. The MITF uses honeypots*25 connected to the Internet in a manner similar to general users
in order to observe communications arriving over the Internet. Most appear to be communications by malware selecting atarget at random, or scans attempting to locate a target for attack.

*20

Attack that overwhelms the network bandwidth capacity of a target by sending massive volumes of larger-than-necessary IP packets and fragments. The use*21

TCP SYN flood, TCP connection flood, and HTTP GET flood attacks. TCP SYN flood attacks send mass volumes of SYN packets that signal the start ofof UDP packets is called a UDP flood, while the use of ICMP packets is called an ICMP flood.

TCP connections, forcing the target to prepare for major incoming connections, causing the wastage of processing capacity and memory. TCP Connection
flood attacks establish mass volumes of actual TCP connections. HTTP GET flood attacks establish TCP connections on a Web server, and then send mass

*22
*23
*24
*25
Vol.5

volumes of HTTP GET protocol commands, wasting processing capacity and memory.

Misrepresentation of a sender’s IP address. Creates and sends an attack packet that has been given an address other than the actual IP address of theattacker in order to pretend that the attack is coming from a different location, or from a large number of individuals.

A “bot” is a type of malware that institutes an attack after receiving a command from an external C&C server. A network constructed of a large number of botsacting in concert is called a “botnet.”

Malware Investigation Task Force (MITF). The MITF began activities in May 2007 observing malware network activity through the use of honeypots in an attempt
to understand the state of malware activities, to gather technical information for countermeasures, and to link these findings to actual countermeasures.
A system designed to simulate damages from attacks by emulating vulnerabilities, recording the behavior of attackers, and the activities of malware.
November 20097

Infrastructure Security

There are many methods that can be used to carry out a DDoS attack. In addition, the capacity of the environment attacked

Infrastructure Security■ Status of Random Communications

Figure 3 shows trends in the total volumes of communications coming into the honeypots (incoming packets) between July 1
and September 30, 2009. Figure 4 shows the distribution of sender’s IP addresses by country. The MITF has set up numerous

honeypots for the purpose of observation. We have taken the average per honeypot, showing the trends for incoming packet
types (top ten) over the entire period subject to study.

Much of the communications arriving at the honeypots demonstrated client-targeted scanning behavior using TCP ports
utilized by Microsoft operating systems. As with the prior study, we observed scanning behavior attempting to exploit 2967/TCP

used by Symantec client software and 4899/TCP used by PC remote management tools. At the same time, communications
for which the goal was not clearly identifiable, such as 53248/TCP and 20689/TCP (not used by general applications), werealso observed. Attacks on 445/TCP, etc., targeting Microsoft vulnerabilities have continued since last October. Looking at theoverall sender distribution by country, we see that attacks sourced to China and Japan, 26.6% and 24.4%, respectively, werecomparatively higher than the rest.

(No. of Packets)
1,200

1,000
800

■Other■4899/TCP■22000/TCP■31138/TCP■20689/UDP■2967/TCP■53248/TCP■1433/TCP■2582/TCP■135/TCP■445/TCP

600
400
200
0
09.07.01

09.08.01(Date)

09.09.01

Figure 3: Communications Arriving at Honeypots (by Date, by Target Port, per Honeypot)
sensor 台数を 61 として計算
time

445/TCP

135/TCP

2582/TCP

1433/TCP

53248/TCP

2967/TCP

20689/UDP

31138/TCP

22000/TCP

4899/TCP

その他

2009.7.1

195.5409836

34.03278689

46.06557377

33.19672131

021.3442623

0.327868852

040.86885246

3.93442623

315.6557377

2009.7.2

181.7704918

49.36065574

45.16393443

11.93442623

0.081967213

037.59016393

9.983606557

231.2295082

2009.7.3
197.8196721
Other 27.4%

42.36065574

47.26229508

15.55737705

0

0

37

8.409836066

305.4098361

2009.7.4
IN 1.2%177.7704918

44.27868852

53.04918033

27.2295082
0
ISP A 6.5%
21.47540984
ISP B0 2.8%

20.6557377

0039.42622951

13.78688525

284.5081967

IT 1.2%
2009.7.5

163.1803279

44.59016393

41.83606557

26.3442623

0.016393443

039.03278689

3.721311475

256.7540984

RU 1.5% 151.4098361
2009.7.6

43.42622951

33.04918033

13.45901639

0027.18032787

12.36065574

217.4098361

37.63934426

29.55737705

9.672131148

0.049180328

023.6557377

2.426229508

197.5409836

43.45901639

36.19672131

13.59016393

0020.98360656

7.672131148

205.6393443

43.3442623

35.98360656

11.31147541

0023.80327869

6.786885246

141.3114754

43.44262295

26.32786885

ISP D0 1.7%
34.80327869
ISP E 1.3%
36.90163934 0
IIJ 1.1%
35.78688525 0
ISP F 1.0%
52.67213115 0
ISP G 1.0%
45.04918033
ISP H0 0.9%

0026.09836066

2.672131148

144.2131148

41.75409836

26.09836066

Other0 7.7%
54.93442623

8.639344262
5.180327869

0.016393443

028.7704918

7.06557377

208.2622951

38.55737705

28.91803279

29.78688525

494.7213115

7.803278689

0.016393443

025.83606557

8.06557377

188.6065574

43.1147541

24.7704918

32.95081967

210.3770492

9.245901639

0.016393443

016.06557377

17.19672131

128.4262295

0

0

16

6.180327869

142.6721311

Outside Japan 73.4%

BR 1.5% 168.0655738
2009.7.7
KR 1.5%2009.7.8
166.3114754
TH 3.3%2009.7.9
174.8196721
TW 3.5%2009.7.10
155.5409836
EU 3.8%2009.7.11
162.4590164
US 4.1%
2009.7.12
CN 24.4% 169.4098361
2009.7.13

156.5245902

Within Japan 26.6%

28.18032787
ISP C0 2.0%

42.19672131ISP 0I 0.6%

2009.7.14
171.2459016Distribution
38.8852459
20.55737705
21.26229508
115.0983607
Figure 4: Sender(Entire Period
underStudy) 7

untry code
A社

BE B 社

NFRA

EB D 社

com E 社
IIJ

F社

G社
H社
I社

その他
CN

2009.7.15

183.4098361

34.04918033

21.04918033

26.8852459

79.16393443

9.803278689

0013.73770492

15.63934426

126.6721311

2009.7.16

177.0327869

57.19672131

19.55737705

36.60655738

67.98360656

19.18032787

0013.70491803

10.03278689

203.6885246

2009.7.17

171.7868852

43.2295082

20.19672131

36.1147541

55.81967213

7.098360656

0012.95081967

5.983606557

203.4754098

2009.7.18

154.3770492

50.67213115

26.78688525

36.04918033

57.98360656

4.590163934

0015.3442623

1.901639344

142.3278689

2009.7.19

140.0983607

44.37704918

34.40983607

34.19672131

42.18032787

20.37704918

0014.72131148

1.606557377

94.67213115

2009.7.20

148.6885246

50.09836066

33.62295082

32.90163934

34.67213115

10.67213115

0014.29508197

1.737704918

104.9344262

2009.7.21

142.5409836

50.54098361

26.27868852

32.50819672

27.18032787

9.180327869

0010.36065574

1.901639344

135.9016393

2009.7.22

139.9836066

37.67213115

29.42622951

37.54098361

23.2295082

19.18032787

0.37704918

19.44262295

9.803278689

10.47540984

135.6065574

2009.7.23

153

39.72131148

27.86885246

25.09836066

21.83606557

7.786885246

045.24590164

9.245901639

9.836065574

138.4590164

0.032786885

55.01639344

9.098360656

16.78688525

106.1639344

ISP/Country2009.7.24
code
6.50%

2.77%
C社

1.69%

1.33%

1.09%

1.03%

0.99%

0.88%

0.58%

7.70%

24.36%

6.5%
2009.7.25

2.8%
2009.7.26

Percentage
Percentage Count
Name
Percentage
157.1803279 39.7704918
29.04918033 35.93442623 16.80327869 17.09836066
751706156.1311475 国内
50.63934426 26.6%
42.96721311

36.67213115

20.31147541

14.04918033

35.85245902

24.44262295

11.52459016

4.344262295

122.6229508

156.2622951

46.04918033

39.6557377

25.7704918

16.98360656

14.80327869

59.47540984

13.40983607

11.04918033

2.196721311

129.9672131

40.39344262

31.44262295

24.18032787

12.55737705

12.1147541

9.344262295

8.409836066

9.819672131

4.62295082

109.3770492

2009.7.27
1.98%

153.0327869
2.0%

151.5737705

44.6557377

30.96721311

32.04918033

10.59016393

23.80327869

5.721311475

11.96721311

8.901639344

1.901639344

108.9672131

2009.7.29

1.3%

154.0983607

57.85245902

28.70491803

21.52459016

11.18032787

9.770491803

3.278688525

14.49180328

9.426229508

0147.6065574

2009.7.30
1.1%

160.0983607

52.26229508

26.26229508

29.2295082

12.72131148

25.3442623

5.147540984

13.08196721

7.06557377

4.098360656

188.3934426

2009.7.31

1.0%

171.557377

55.6557377

23.93442623

21.85245902

13.24590164

22.2295082

42.06557377

11.27868852

8.213114754

5.803278689

196

2009.8.1

156.8688525

81.80327869

29.21311475

31.13114754

12.31147541

19.91803279

4.655737705

12.16393443

9.557377049

3.983606557

144.442623

2009.8.2

144.852459

160.8688525

36.75409836

25.81967213

12.13114754

22.21311475

10.09836066

20.39344262

9.131147541

30.04918033

222.6393443

144.9344262

20.63934426

28.7704918

24.37704918

7.950819672

24.98360656

33.16393443

41.09836066

6.62295082

6.68852459

118.3114754

141.8688525

48.80327869

35.40983607

33.93442623

7.803278689

25.83606557

22.1147541

49.1147541

6.704918033

2.967213115

119.6557377

262.147541

55.55737705

35.55737705

25.86885246

6.721311475

27.19672131

0.213114754

59.04918033

5.327868852

6.901639344

136.6229508

24.08196721

5.081967213

21.37704918

36.40983607

50.21311475

6.131147541

5.475409836

145.4754098

2009.7.28
1.7%

Vol.5 November 2009
1.0%

0.9%
2009.8.3

0.6%
2009.8.4

7.7%
2009.8.5

24.4%
2009.8.6

2082084
152.8852459 国外
55.90163934 73.4%
33.85245902

8

■ Malware Network Activity

Infrastructure Security

Date
総取2009.7.1 341
2009.7.2 332
specimens acquired during the period under study. Figure 6 shows the distribution of the specimen acquisition source for malware.
2009.7.3 366
26
In Figure 5, the trends in the number of acquired specimens show the total number of specimens acquired per day* , while the2009.7.4 664
number of unique specimens is the number of specimen variants categorized according to their digest of a hash function*27.
2009.7.5 497
2009.7.6 504
2009.7.7 577
On average, 592 specimens were acquired per day during the period under study, representing about 46 different malware
2009.7.8 325
variants. According to the statistics in our prior whitepaper, the average daily total for acquired specimens was 708, with 60
2009.7.9 724
different variants, indicating a slight decline in average number of specimens and number of variants.
2009.7.10 641
2009.7.11 605
2009.7.12 460
The distribution of specimens according to source country has Japan at 64.4%, with other countries accounting for the 35.6%
2009.7.13 568
balance. Of the total, malware infection activity among IIJ users was 1.5%—a significant decrease compared to the 16.8%
2009.7.14 584
figure reported in our prior whitepaper. Looking more closely at the malware variants, after June of this year, we see that this2009.7.15 364
2009.7.16 621
trend has resulted from a dramatic decline in activities attempting to infect computers with Virut*28 and its variants and activities2009.7.17 536
29related to Sdbot* and its variants on the IIJ network.
2009.7.18 425
2009.7.19 814
2009.7.20 513(Total No. of Specimens Acquired)(No. of Unique Specimens)
1,800
2009.7.21 438
120■Total No. of Specimens Acquired
2009.7.22 501■No. of Unique Specimens
1,600
100
2009.7.23 493
1,400
2009.7.24 458
1,200
80
2009.7.25 533
1,000
2009.7.26 642
60
2009.7.27 514
800
2009.7.28 564
600
40
2009.7.29 506
400
2009.7.30 596
20200
2009.7.31 672
002009.8.1 754(Date)
09.07.01
09.08.01
09.09.01
2009.8.2 176
2009.8.3 256
Figure 5: Trends in the Number of Malware Specimens Acquired (Total Number, Number of Unique Specimens)
2009.8.4 578
2009.8.5 520
Count
ISP/CountryCode
ISP/Country code
Percentage Percentage Count
Outside Japan 35.6%
Within Japan 64.4%
2009.8.6 Name
773
Other 2.0%
2009.8.7 808
14744
ZAQ(9617) A 社
27.70%
27.7%
34240
国内
64.4%
EU 0.1%
2009.8.8 874
7461
BIGLOBE(2518)
B社
14.02%
14.0%
US 0.1%
2009.8.9 744
4771
INFOWEB(2510)
C社
8.96%
9.0%
PH 0.2%
ISP A 27.7%
2009.8.10 860
VN 0.4%
3762
OCN(4713)D 社
7.07%
7.1%
2009.8.11 910
AU 0.8%1046
STNET(7522)
E社
1.97%
2.0%
KR 1.0%2009.8.12 768
ISP B 14.0%
I N 2.8%
773
IIJ(2497) IIJ
1.45%
1.5%
2009.8.13 802
ISP
C
9.0%
TW 6.8%2009.8.14 541
708
UCOM(17506)
F社
1.33%
1.3%
ISP D 7.1%
TH 7.8%ISP E 2.0%
2009.8.15 668
CN 13.6%
634
DION(4732)
G社
1.19%
1.2%
IIJ 1.5%
2009.8.16 419
177
KDDI(2516)
H社
0.33%
0.3%
ISP F 1.3%
2009.8.17 982
123
KMN(17529)
I
社
0.23%
0.2%
ISP G 1.2%
2009.8.18 1695
ISP H 0.3%
41
others
その他
0.08%
0.1%
2009.8.19 662
Figure 6: Distribution of Acquired Specimens by Source
ISP I 0.2%
7244
CN
CN
13.61%
13.6%
18989
国外
35.6%
2009.8.20 851
Other 0.1%
(Entire Period under Study)
2009.8.21 548
4154
TH
TH
7.80%
7.8%
2009.8.22 640
3600
TW
TW
6.76%
6.8%
2009.8.23 790
1513
IN
IN
2.84%
2.8%
*26 This indicates the malware acquired by honeypots.
2009.8.24 522
513
KR
KR
0.96%
1.0%
*27 This figure is derived by utilizing a one-way function (hash function) that outputs a fixed-length value for various input. The hash function is designed to2009.8.25 681
435
AU
AU
produce as many different outputs as possible for different inputs. While wecannot guarantee
the uniquenessof0.82%
specimens 0.8%
by hash value, given that2009.8.26 442
203
VNvalues, theVN
0.38% its best
0.4%
obfuscation and padding may result in specimens of the same malware having
different hash
MITF has expended
efforts to take this fact
2009.8.27 449
into consideration when using this methodology as a measurement index.
2009.8.28 342
108
PH
PH
0.20%
0.2%
*28 Virut is a virus spread through an infected file, and is not generally spread throughnetworks.
of thisvirus was attempted
as the result of
2009.8.29 760
65
US The propagation
US
0.12%
0.1%
an attack exploiting a vulnerability. See Trend Micro’s explanation of Virut (http://threatinfo.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=MAL_
2009.8.30 486
46
EU
EU
0.09%
0.1%
VIRUT). Also see an alert from the Information-Technology Promotion Agency, Japan (IPA) regarding Virut propagation via web content (http://www.ipa.go.jp/
2009.8.31 620
1108
others
その他
2.08%
2.0%
security/txt/2009/03outline.html)(in Japanese). A similar attempt to propagate malware was detected at the Cyber Clean Center, suspected to be related to2009.9.1 494
other malware infection activities (https://www.ccc.go.jp/report/200907/0907monthly.html)(in Japanese).
2009.9.2 256*29 An Sdbot is a type of bot conducting communications with the C&C server via IRC. See Trend Micro’s explanation of the Sdbot (http://threatinfo.trendmicro.
2009.9.3 288
com/vinfo/virusencyclo/default5.asp?vname=WORM_SDBOT.GEN).
2009.9.4 680
2009.9.5 447
2009.9.6 318
Vol.5 November 20099
2009.9.7 532
2009.9.8 531
2009.9.9 444
2009.9.10 596
2009.9.11 695

Next, we will take a look into the malware activity observed by the MITF. Figure 5 shows trends in the total number of malware

Infrastructure Security

The MITF prepares analytical environments for malware, conducting its own independent analyses of acquired specimens. The
results of these analyses show that during the period under observation, 4.5% of the malware specimens were worms, 89.6%

were bots, and 5.9% were downloaders. In addition, the MITF confirmed the presence of 44 botnet C&C servers*30 and 548
malware distribution sites.

1.3.3 SQL Injection Attacks

Of the types of different Web server attacks, IIJ conducts ongoing surveys related to SQL injection attacks*31. SQL injection

attacks have flared up in frequency numerous times in the past, remaining one of the major topics in the Internet security. SQL
injections are known to occur in one of three attack patterns: those that attempt to steal data, those that attempt to overload
database servers, and those that attempt to rewrite Web content.

Figure 7 shows trends of the numbers of SQL injection attacks against Web servers detected between July 1 and September

30, 2009. Figure 8 shows the distribution of attacks according to source. These data are a summary of attacks detected bysignatures on the IIJ Managed IPS Service. Japan was the source for 67.3% of attacks observed, while China and the UnitedStates accounted for 11.6% and 4.9%, respectively, with other countries following in order.

We noted a decrease in SQL injection attacks on web servers compared with our prior whitepaper. While the total number of
SQL injection attacks declined, the decrease among source countries outside of Japan was particularly notable. Accordingly,
the ratio of attacks sourced to Japan experienced a significant increase.

その他

As previously shown, attacks of various types were properly detected and dealt with in the course of service. However, suchattacks are constant and ongoing, calling for continued vigilance.

HTTP̲

HTTP̲

HTTP̲

(No. Detected)

HTTP̲

800

HTTP̲

700

■Other■ HTTP_GET_SQL_Select_Top_1

600■ HTTP_OracleApp_soap

500■ HTTP_GET_SQL_UnionSelectHTTP̲■ HTTP_OracleAdmin_Web_Interface

URL̲D■ HTTP_IIS_MSSQL_XML_Script

URL̲D■ URL_Data_SQL_char

SQL̲In■ HTTP_GET_SQL_Convert_Int

400■ URL_Data_SQL_Cast_parentheses

300

URL̲D

200

■ URL_Data_SQL_1equal1

100■ SQL_Injection

0
09.07.01

09.08.01(Date)

09.09.01

Figure 7: Trends in SQL Injection Attacks (by Day, by Attack Type)
Other 12.5%
ID 0.3%
SQL_Injection URL_Data_SQL_char
日付
FR 0.4%
HTTP_GET_SQL_UnionSelectHTTP_OracleApp_soap

HTTP_GET_SQL_Select_Top_1

2009.7.2

02009.7.1

2009.7.3

2009.7.4

2009.7.5

2009.7.6

2009.7.7

2009.7.8

2009.7.9

304
TW 0.4%
85

38

7

179
AR 0.7%
82

36

12

10

SG 0.4%161

227
BR 0.7%109
KR 0.8%161

2009.7.10

194
US 4.9%205

2009.7.12

75

2009.7.11

2009.7.13

2009.7.14

2009.7.15

2009.7.16

2009.7.17

2009.7.18

2009.7.19

2009.7.20

2009.7.21

2009.7.22

66 11.6%
CN
78

124

101
97

165
*30
57

*31

183
73

143
73

19

52

13

54
7

54

49
6

8

14
8

30

39
3

32

34
7

2009.7.25

74

2

2009.7.27

2009.7.28

2009.7.29

20

89

69

190

12

24
1

12
7

3

3

6

1

9

12

0

0

0

6

0

0
JP 67.3%
0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

6

6

0

0

0

0

6

0

0

0

6

0

0

3

6

43
0

0

0

5

0

5

5

0

0

0

0

27

0

0

0

0

60

4

0

0

0

0

0

8

0

12

0

0

0

0

without proper
authorization,and stealor rewrite
Web content.
37
14
0 sensitive information
0002009.7.23

2009.7.26

180HTTP_OracleAdmin_Web_Interface

CN
2540
0
0
0
50
US
1076 0
0
0
0
0
56
KR
184
0
0
0
0
83
BR
147
0
0
0
0
17
0
73 AR
0
0
26
145
0
0
0
0
69
SG
96
0
0
1
0
53
TW
96
0
0
2
0
93
FR
0
0
55 80
2
313
0 Figure 8:1Distribution
0ID
74
of SQL0 Injection84Attacks by
0
17
13
Sourceその他 0 2734 0
その他

0

3

1

0

0

0

0

0

4

3

12

0

1

0

18

111
44

42

71

53

Attacks accessing a Web server to send SQL commands, thereby manipulating an underlying database. Attackers access or alter the database content

November
29 2009

306

3

JP
14736
HTTP_IIS_MSSQL_XML_Script URL_Data_SQL_Cast_parentheses

16
2
0 A server that0 provides commands
0010
Abbreviationof “Command& Control.”to a2botnet consistingof a large0number of bots.

Vol.5
172

2009.7.24

2

URL_Data_SQL_1equal1

20

22

28

25

11

10
0

8

0

0

2

9

0

2

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

6

0

0

2

0

0

10 0

0

0

7

0

10
0

0

0

0

0

0

0

0

0

51
0

0

0

0

1

3

0

0

0

0

3

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

4

0

0

28

17

52

105
67

68

17

39

36

71

42

HTTP_GET_SQL_

Incidents occurring over the Internet change in type and scope almost from one minute to the next. Accordingly, IIJ works
toward taking countermeasures by performing independent surveys and analyses. Here we will present information gatheredfrom surveys performed during the period from July 1 and September 30, 2009 related to DDoS attacks in the United Statesand South Korea, TCP vulnerability (Sockstress), and randomly arriving SIP packets.

1.4.1 DDoS Attacks in the United States and South Korea

In early July 2009, websites in the United States and South Korea were victimized by a series of simultaneous DDoS attacks*32.

In this section, we will discuss the circumstances of these attacks, based on information obtained by IIJ.
■ DDoS Attack Background

This particular series of DDoS attacks did not use botnets so widely encountered today, but rather malware designed specificallyfor these attacks. It is reported that this specially designed malware propagated through websites inside South Korea used forfile sharing*33. Because of this, many of the IP addresses traced as the source of the attack reportedly have been identified
as South Korean IP addresses*34. Malware files of a similar type were placed on similar web services outside South Korea,

infecting PCs in other countries*35. While it is unclear as to what timeframe these infection activities took place, it is believed thatthe propagation activities took place in a concentrated period immediately before the DDoS attacks in order to evade detection
and countermeasures by anti-virus software vendors*36. The total number of PCs infected by the malware is undetermined, but

a subsequent announcement out of South Korea indicated that the infection affected approximately 78,000 machines within
the country*37.

The DDoS attacks first occurred on July 5*38 and July 6 (Korean time), mainly targeting multiple government agencies’ web

servers in the United States. After July 7, the attacks moved to multiple websites in South Korea. The attacks in South Korea
affected not only government agencies, but also online banking sites, webmail services, and other popular online consumer

services. It has been reported that the infected PCs used for the DDoS attacks did not generate significant amounts of traffic
singly. Rather than occupying communication lines using massive volumes of traffic, the attacks mainly put a direct load on thetarget servers*39.

This particular DDoS attack died down on July 10, eventually running its course*40. That the malware was cleaned from 95%of the approximately 78,000 machines infected within four days was mostly due to the efforts of South Korean ISPs, security

organizations, and media*41. As a result of these efforts, the DDoS attack converged as of July 10. There was a report that only
several hundred hard drives were destroyed as a side effect of infection with the malware.

*32

F-Secure reported on its blog that several websites in the United States became inaccessible because of this DDoS attack (http://www.f-secure.com/weblog/*33

Web-based file-sharing services (so-called “uploaders” in Japan) are used frequently in South Korea by corporations and educational institutions. It is believed

*34
*35
*36
*37
*38
*39
*40
*41

archives/00001720.html). South Korean news organizations also reported that several websites in that country became inaccessible due to the attack.
that many users became infected when files containing the malware infection package were uploaded to several of these services.

The following report states that more than 100,000 PCs were conscripted in this attack, between 90% and 95% of which were located in South Korea (http://
www.shadowserver.org/wiki/pmwiki.php/Calendar/20090710).

The following is an alert from JPCERT/CC discussing the attack from Japan, “DDoS attack against Web sites in South Korea and US” (http://www.jpcert.or.jp/
at/2009/at090012.txt)(in Japanese).

As one circumstantial evidence, a specimen obtained and studied by IIJ forged a file creation date of 2004, while the time stamp in the PE header of each file
showed a date immediately prior to the launch of the attack, “July 4, 2009 0:38” for perfvwr.dll as an example.

Information related to the number of affected machines inside South Korea is detailed in a presentation at APNIC28 by KRNIC of KISA (Korean Internet &Security Agency) (http://meetings.apnic.net/__data/assets/pdf_file/0019/14077/lee-ddos-attack.pdf).

The first attack began at 2am, July 5 Korean local time. The time was 13:00 EDT July 4 (Independence Day) in the United States. There is no time zone
difference between Korea and Japan.

For example, the following alert from KrCERT indicates the circumstances of the DDoS attack traffic from this malware (http://www.krcert.or.kr/noticeView.
do?num=340). (in Korean)With traffic returning to normal levels, the Korean NCSC (National Cyber Security Center) lowered its warning level from an “alert” to a “notice” on July 12.

According to the details published by KrNIC in APNIC28 (http://meetings.apnic.net/28/program/apops/transcript#ji-young-lee). Subsequent to the DDoS
attack in South Korea, information about the malware used in the attack and tools dedicated to eliminate the malware were promptly provided by several anti-

virus vendors. Television news programs and popular web services issued notifications regarding the attack in conspicuous ways in efforts to alert the public

and publicize information regarding corrective action. Information was also released notifying users that backing up their system clocks to an earlier time wasan effective temporary measure against one of the malware variants that would destroy hard drives on a specific date (July 10).
Vol.5

November 200911

Infrastructure Security

1.4 Focused Research

Infrastructure Security■ Malware used in the DDoS Attacks

Once this attack occurred, IIJ first obtained several malware specimens from general malware-related information sources andorganizations. These specimens included malware that first induces malware infections for DDoS attacks, malware containing
functions for actual DDoS attacks and malware that continues to update attack targets.

Having analyzed and conducted demonstration tests on these specimens, we learned that the malware utilized in these attacks
behaved as shown in Figure 9*42.

First, the initial malware package (msiexec*.exe, etc.) drops (creates) two types of malware (perfvwr.dll (or wmiconf.dll)
and wmcfg.exe) (1). The malware perfvwr.dll (or wmiconf.dll) first turns off the personal firewall of the infected PC prior tocommencing the attack. Next, the infected PC connects to three separate servers, creating a configuration file (uregvs.nls)

for the attack (2). The perfvwr.dll and wmiconf.dll malware files start a DDoS attack according to the configuration file (3).
The configuration file contains the length of time, target server, attack type and number of attacks for the DDoS attack. Thismalware-based attack is performed as shown in Figure 9 (4), in accordance with the configuration file. The results of the IIJ
demonstration tests showed that the attack traffic generated per machine was 110pps for TCP SYN flood, 110pps for TCP ACK

flood, and around 216pps for UDP and ICMP floods, with 107cps (commands per second) for HTTP GET flood and HTTP

POST flood. We also observed behavior of intermittent increases and decreases in communications via program-embedded
temporary suspension command.

Meanwhile, wmcfg.exe drops two more files—mstimer.dll and wversion.exe (5). The mstimer.dll file downloads a file calledflash.gif from multiple web servers (6), extracting and updating a file called wversion.exe from flash.gif (7), while at the sametime sending spam to multiple addresses (8). The wversion.exe file deletes the mstimer.dll file and itself, removing evidence(9). However, a function is inserted after the update to search and destroy files on the hard drive having certain extensions (10),writing certain character strings to the hard drive MBR*44, and preventing the PC from being turned on (11).

(4) DDoS Attack Behavior(2) Create

Download• Reads the configuration file (uregvs.nls), creates 30 attack threads for eachtarget host, and conducts the following attacks in parallel.

Updated on Three Servers• Attack Target Information
Updatedmsiexec2.exe, etc.
• Creates uregvs.nls• Deletes itself• Two TCP SYN floods, two TCP ACK floods, two UDP floods, two ICMP

floods, one ICMP smurf attack, two HTTP GET floods (or HTTP POST

uregvs.nls(configuration file
indicating attack
target, attack time, etc.)

Readfloods depending on the configuration) for a total of 11 attacks, repeated.

• Of the two TCP SYN flood, TCP ACK flood, UDP flood and ICMP flood
attacks, one uses IP spoofing (false IP address).

• Under HTTP GET flood, a mechanism for impersonating a general user

(3) DDoS Attack(1) Drop
Access(user agent designation, prohibition against using the cache, etc.) and aconfiguration for placing a communications load on a server are used*43.

GET Flood
TCP/UDP/ICMP Floodperfvwr.dll(wmiconf.dll)• Executes DDoS attack• Turns off personal firewall• Attack volume varies according to time based on temporary suspension
command located within the attack code.

Attack Target Hosts(8) Mass mailing(5) Drop(8) Mass Mailing Activities• Searches for specific files, and collects email addresses.

(6) Download

msiexec1.exe, etc.

• Drops Malware• Accesses update server• wmiconf.dll service registration• Deletes itself• Sends SPAM mails (Subject “memory of …”; From
“Independence”) to multiple addresses.

mstimer.dll

DownloadServers(several dozen)(1) Drop• Mass mailing• Downloads flash.gif• Extracts new wversion.exe fromflash.gif and executes

flash.gif(11) HDD destruction• A new wversion.exe
attached after the image

wmcfg.exe(7) Executable file
extraction• Drops malware• mstimer.dll service registration• Deletes itself

SPAM email

HDD(10) (11) HDD, File Destruction• mstimer.dll downloads flash.gif from the download server; extracts
wversion.exe; performs update and executes.

• The new wversion.exe file searches for files having certain extensions on July
10, and destroys them.

• Also on July 10: malware writes a certain character string (“Memory of the(5) Drop

Update(9) wversion.exe (old)• Deletes mstimer.dll• Deletes itself

Independence Day…”) to the HDD MBR, preventing the PC from being(10) File destruction

wversion.exe (new)• Destroys certain files• Destroys HDD data

turned on.

File• Deletes mstimer.dll (file, service).
• Deletes itself.

Figure 9: Behavior of Malware used in DDoS Attacks*42

Our descriptions of this behavior is based on our best efforts at directly gathering information; however, the description includes some information that IIJ was*43

Various patterns were noted; character strings forged Firefox, IE7.0, or IE8.0 in the User-Agent header. “ko” (Korean language) was designated in the Accept-

*44

Vol.5

not able to directly confirm about the roles and status of various Internet servers at the time of the DDoS attack.
Language header. The Cache-Control header of some requests showed no-store, must-revalidate.

MBR: Acronym for Master Boot Record. The MBR is a region at the front of the hard drive; normally programs used for launching the computer’s operating
system are stored in this region.
November 200912

Figure 10 shows the chronological order of the progression and related events for the attack described in this section.
Normally, DDoS attacks are designed for harassment or other clear intent targeting a certain website, and are generally one
type of security incident for which the purpose is comparatively easy to identify. The DDoS attack described here, however,

was highly complex (malware propagates within South Korea first, attacks targets in the U.S. and then South Korea*45 andintervening malware divides into two independent malware packages, etc.) and the purpose was difficult to identify.
■ Measures against This Particular Type of DDoS Attacks

Here, we will consider the difference between the measures against the damages incurred due to this particular DDoS attack
and those that would normally be taken against a DDoS attack. This attack consisted of the mass operations of numerous PCs
infected with the malware, making it difficult to institute access or bandwidth controls for the individual PC IP addresses fromwhich the attack traffic was generated. However, much of the attack traffic originated from within one country, and performing

access and bandwidth controls on a network basis appeared to be an effective temporary countermeasure. A characteristic of
this incident was the low volume of attack traffic from individual PCs infected with the malware. In particular, the web requests

involved in the attack were disguised to imitate user behavior, making the determination between normal and attack traffic
comparatively difficult. Even if anti-DDoS equipment were available, some adjustments would have been required to establish
the abnormal behavior detection threshold and operating mode configurations.

At IIJ, we believe it is necessary to research measures that would deal with this type of DDoS mechanism if such an attack
were to take place within Japan. Where the malware executed an attack based on a configuration file distributed beforehand,rather than dealing with the attack by taking action against a centrally controlled botnet, the only solution for stopping such an
attack is to eliminate the malware on each individually infected PC. As we saw take place in South Korea, to promptly delete

the malware from so many individual PCs requires the cooperation and coordination of many different organizations. To be able

to accomplish something on this scale, organizations must be vigilant and ready to engage in synergistic action when called
for*46.

Malware Infection DDoS Attack

Prior to July 4
Infection propagatedthrough file-sharing
services in South Korea

U.S. Web Servers Attacked
South Korean Web Servers Attacked

7/4 17:00-7/5 5:00
8 Websites

7/7 9:00-7/8 9:00
13 Websites

7/8 9:00-7/9 9:00
14 Websites

7/9 9:00-7/10 9:00
7 Websites

7/7 12:00-22:0013 Websites

7/5 13:00-22:0021 Websites* These attacks were defined by one configuration file

7/5 13:00-7/6 9:00
21 Websites

SPAM email sent
File destruction
HDD destruction

7/4

7/5

7/6

7/7

7/8

7/9

Number of targets includes those reported in media plus targets confirmed by IIJ

Figure 10: DDoS Attacks against the United States and South Korea: Chronological Order (UTC)

*45

*46

According to the specimen acquired, 13 U.S. websites (from July 7, 2009 18:00 to July 8 18:00) and 13 South Korean websites (from July 7, 2009 21:00 to
July 8 7:00) were attacked under the configuration in the same file. We see that this is the dividing line between where the attacks transitioned to domestic
South Korean servers.

In Japan, cyber security exercises have been conducted such as those sponsored by "Anti-Cyber Attack Exercises in the Telecommunications Business
Sector"(http://www.soumu.go.jp/menu_news/s-news/2006/061201_4.html) (in Japanese) of the Ministry of Internal Affairs and Communications, and thoseby Telecom-ISAC Japan (https://www.telecom-isac.jp/english/index.html). There also have been international exercises including APCERT drills (http://www.
apcert.org/documents/pdf/APCERT-drill-2008.pdf). IIJ actively participates in these exercises.
Vol.5

November 200913

Infrastructure Security■ Summary of the Attack

Infrastructure Security

1.4.2 TCP Vulnerability (Sockstress)

In September 2009, Finnish CSIRT organization CERT-FI published the state of the response to vulnerabilities related to TCP.

*47 This announcement was picked up widely in the press. In this section, we will explain these TCP vulnerabilities and responses.
■ Background

The vulnerabilities themselves were first identified one year prior to the Finnish announcement. Two researchers from asecurity vendor Outpost24 first identified the issue. These researchers developed a tool to speed up network scanning called
Unicornscan*48. During their use of this new tool, they happened to notice unexpected behavior in TCP, and created a tool
called Sockstress*49 to generate traffic that exploited this behavior (this tool has not been publicly released).

Based on the information demonstrating the existence of these vulnerabilities, CERT-FI took the lead in organizing a communitythat encouraged product developers to take appropriate measures. In Japan, this issue is being handled by the Information
Security Early Warning Partnership*50.
■ Details of the Vulnerabilities

The tool for exploiting these vulnerabilities (Sockstress) has not been released to the public, nor have the complete details

about these vulnerabilities been disclosed. Here, we offer a commentary regarding “zero window size,” which has been mostwidely discussed in the public.

An attack using zero window size occurs as follows:
サーバ

1. Establish a TCP connection from a client to a server.

2. During communications, the client specifies zero as its

receive window size to declare “buffer full, cannot receive

Connection

any more data.” In this state, the server will temporarilysuspend data transmission via this TCP connection.

Attacker

The server will continue to query the current client-side①

receive window size in certain intervals, maintaining the＝0Server
SYN

Establish TCP
connection

SYN/ACK
ACK

接続の保持
connection
as long as a response is received.

3. Steps 1 and 2 above from client to server are repeated
データ送信停止②

Window size=0

Set window size to 0

over and over again.

4. Server resources are exhausted, and new TCPWindow size query

connections cannot be accepted.

合わせ

＝0

Connection maintained
Data transmission
suspended

Window size=0

In fact, the time for an attack to become effective depends on③

the server implementation, resources and capacity. It is also

Maintain a high-volume connection

Connection management
information
Connection management
information
Connection management
information

possible that while the load climbs high, an attack doesn’t
become successful.

Attacker

ServerConnection management
information
Connection management
information
Connection management
information

接続管理情報

Maintaining a connection under a zero window size state is
接続管理情報actually a normal operation under TCP standards RFC793*51

Figure 11: S erver-side stack through zero window size
designationsand 接続管理情報
RFC1122*52. Even regular clients using TCP for
接続管理情報

サーバ

*47
*48

接続管理情報Response to TCP vulnerabilities (https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html) (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-

接続管理情報2008-4609) (http://www.microsoft.com/technet/security/bulletin/ms09-048.mspx), etc.

*49
*50

Unicornscan (http://www.unicornscan.org/).

While Sockstress itself has not been released publicly, related information has been summarized (http://sockstress.com/).

The Information Security Early Warning Partnership is a framework for vulnerability information dissemination to product developers based on the Ministryof Economy, Trade and Industry directive #235. Under this partnership, the IPA (http://www.ipa.go.jp/security/english/quarterlyrep_vuln.html#Partnership)acts as the vulnerability information reception agent, while the JPCERT Coordination Center (http://www.jpcert.or.jp/english/vh/project.html)serves as thecoordinating agent to product developers. Information about vulnerabilities is published through JVN (http://jvn.jp/en/). IIJ participates in this partnership as a
*51
*52
Vol.5

developer of proprietary router and other products.

RFC793 Transmission Control Protocol (http://www.ietf.org/rfc/rfc793.txt).

RFC1122 Requirements for Internet Hosts - Communication Layers (http://www.ietf.org/rfc/rfc1122.txt).
November 200914

designation of zero window size can be used to mount an attack, presenting a method that forces the server to maintain TCP

connections at volumes exceeding system resources. However, this zero window size attack is not a new method. For example,
the IETF*53 TCPM Working Group*54 broached this subject in July 2006*55, well before the advent of Sockstress.
■ A Protocol Issue or an Implementation Issue?

As shown above, the zero window size designation is a normal state according to protocol specifications. However, a large
volume of TCP connections in this state is seen as an issue. To resolve this issue, arguments call for either making changes to
the TCP protocol itself, or establishing a timeout value or other adjustment in the implementation as a workaround.

Arguments in the earlier-mentioned IETF TCPM Working Group state that this type of attack is an issue of the OS or server
implementation resource management. The consensus is that the solution should be made within implementation inconsideration of individual circumstances, rather than treating this as a protocol issue.
■ Effectiveness of Countermeasures

IIJ picked up the Microsoft patch as one means of dealing with this zero window size issue and performed demonstration testsof an implementation before and after applying the patch. Figure 12 shows the results of this test*56.

As shown in the results of this test, the patched implementation demonstrates a stronger resistance to this type of attack.
However, this countermeasure forces the termination of existing TCP connections to make room in resources to accept newconnections. We have to admit that important connections may also be unavoidably terminated. This countermeasure does

not completely prevent this type of attack. Not only Microsoft, but many of the other entities publishing a patch dealing with thisissue have adopted measures that similarly control the usage of limited resources.

Attack Test Machine

ServerHigh volume of connections maintained

due to malicious use of zero window size

Disabled

ClientTime
Physical Memory Usage for
Non-Paged Memory

Normal Requests

Web Server
Response Rate

* After a certain point, the web server response rate was “0.” When
shut down, the OS encountered an abnormal termination (bluescreen) and experienced other abnormal behavior.

Server OS Environment: Windows Vista + MS09-048 patch

EnabledServer Software: Attack target – program designed for the test
Client Connection – Web Server IIS 7.0

Test:

Execute an attack from the attack test machine to the server for a given period of time.
At the same time, attempt to connect from the client to the server at given intervals,

Time

recording whether or not the server responds.

Physical Memory Usage for
Non-Paged Memory

The Memory Pressure Protection (MPP) function incorporated in the MS09-048 patch
was enabled and disabled, and the results were compared.

Web Server
Response Rate

* The response rate dropped temporarily, but improved with newconnections. The OS exhibited no abnormal behavior. However,existing connections were terminated in order through MPP.

Figure 12: Demonstration Test and Results*53

IETF is the acronym for the Internet Engineering Task Force. An organization that develops the standardization of Internet technologies. (http://www.ietf.org/)*55

Discussion launched on the TCPM WG mailing list (http://www.ietf.org/mail-archive/web/tcpm/current/msg02189.html) and subsequently submitted Internet

*54

*56

TCPM is a short name for TCP Maintenance and Minor Extensions Working Group (http://www.ietf.org/dyn/wg/charter/tcpm-charter.html).
Draft “Clarification of sender behavior in persist condition” (https://datatracker.ietf.org/drafts/draft-ananth-tcpm-persist/), etc.

In fact the Microsoft Web Server, Internet Information Service (IIS) includes functions to adjust web response according to OS load status. Simply performing
the attack in question on the Web Service did not result in abnormal OS behavior. Accordingly, this experiment used this attack to place loads on otherservices.

Vol.5

November 200915

Infrastructure Security

communications can designate zero window size as normal communications control. The issue pointed out here is that theInfrastructure Security

As we have shown, this issue has been treated as an implementation vulnerability. However, because one cannot tell an

attack connection from a normal connection from TCP standards, one has to conclude that this is an issue of system resource

management for systems that receive a large volume of connections. There might be other similar issues that cannot be

fundamentally resolved through implementation modifications*57, and it is likely that more will be uncovered in the future.

Accordingly, servers open to the Internet must be carefully operated continuously.

1.4.3 Randomly Arriving SIP Packets■ Fraudulent SIP Communications

From last year, IIJ has continued to observe SIP (Session Initiation Protocol)*58 packets intermittently arriving at honeypots.

These SIP packets were sent to large numbers of IP addresses across the Internet, attempting to connect to terminals that
could interpret SIP. Depending on the configuration, certain VoIP routers and IP telephones play a ring alert merely at the arrivalof these SIP packets. This was the underlying cause behind the large number silent call reports*59.
■ SIP-Based VoIP Communication Mechanism

As indicated by the name, SIP is one protocol used to control a session, based on a request-and-response model similar to

HTTP. SIP is used in IP phone services and other VoIP communications. However, while the HTTP specification defines datatransmission as well, SIP only controls the initiation, modification, and termination of a session between VoIP terminals, leaving

data transmission to other protocols such as Real-time Transport Protocol (RTP)*60 for audio, etc. Figure 13 shows an exampleof SIP communications via IP telephone.

(1) When a call is initiated via IP telephone, the origin of the call (User Agent:UA) first sends an INVITE message to the call receiver.
(2) When the call receiver gets the INVITE message, a ring tone is sounded to notify the called user. At the same time,“180Ringing” (meaning that a call is in progress) is returned to the originator of the INVITE message.

(3) When the call target picks up the receiver, the receiving terminal sends a 200 OK message to the originator of the call.

(4) Having received this message, the originator of the call sends an ACK response to the call receiver, and the session isestablished.

This is the basic operation. In general, SIP servers are used when connecting, rather than directly connecting the twoterminals*61.

Terminal (User Agent)

Terminal (User Agent)■ Attacks Targeting IP-PBX

To control adoption and maintenance costs, more corporations

SIP

today are replacing existing PBX*62 systems with IP phonesystems using IP-PBX*63. With the availability of low-cost
IP-PBX appliances, it is likely that this trend will continue togather momentum.

Call Request

INVITE sip:

INVITE

foo@****tran

sport=udp SIP/2.0

180 Ringing

Ringing

200 OK

Accepted

ACK

While IP-PBX does present significant adoption benefits

Audio Callin terms of cost savings, different than existing telephone

SIP

Session Established

Audio Data

networks, IP-PBX is connected to a network that features

Aud

other connections with non-VoIP equipment, including the*57

Figure 13: Initiating SIP-Based Audio Communications

For example, a survey report on TCP robustness by CPNI of United Kingdom (https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf) anda summary survey report of existing TCP/IP vulnerabilities by the IPA (http://www.ipa.go.jp/security/vuln/vuln_TCPIP.html)(in Japanese). These reports
publicized several of these issues, providing developers with commentary on important points related to TCP/IP protocol stack implementations. The latter

*58
*59
*60
*61
*62
*63
Vol.5

report also includes a guide for system operators.

We also addressed random SIP packets in Vol.4 of this report (http://www.iij.ad.jp/en/development/iir/pdf/iir_vol04_EN.pdf).

For example, a cNotes article reported this incident. “INVITE Flood? Fraudulent SIP Calls” (http://jvnrss.ise.chuo-u.ac.jp/csn/index.cgi?p=INVITE+Flood%3F++%C9%D4%C0%B5% A4%CASIP%C3%E5%BF%AE)(in Japanese).

Real-time Transport Protocol is a data transfer protocol for transmitting a data stream in real time. Used for audio and video transmission, most VoIP equipment
supports RTP.

An SIP server includes proxy, redirect, and register functions; normally, communications with another party are handled via SIP servers.

A PBX (Private Branch eXchange) is a telephone exchange local to a particular office. It connects internal and external (public switched telephone network)lines and controls incoming and outgoing calls.

A PBX that includes VoIP functions. Asterisk (http://www.asterisk.org/) is one example.
November 200916

and internal attacks than a traditional PBX. Most of today’s VoIP products utilize SIP on UDP; accordingly, SIP packets with false

IP addresses and caller phone numbers can be easily created. In fact, there have been cases overseas of hackers exploiting
vulnerabilities to fraudulently operate an IP-PBX, capturing IP telephone service contract information in an attempt at fraudulent

use*64. Other cases have involved numerous phone calls with false caller numbers, attempting to have the callees call backto premium toll numbers, thus fraudulently building up charges and stealing money*65. The random SIP packets observed by
IIJ were not for the purpose of causing silent calls, but more likely attempts to find IP-PBXs having an exploitable vulnerability.
■ VoIP Security Countermeasures

It is vital to always operate equipment correctly and securely. For example, gain a correct understanding of the types of threats

involved*66, receive periodic updates regarding recommended settings and product information from your VoIP equipmentvendor, confirm important issues related to service usage with your ISP, etc. If possible, configure VoIP equipment withencryption functions, enable settings to only accept SIP packets from certain SIP servers, and incorporate other appropriate
access controls via functions and settings to prevent SIP messages from unknown sources. Adopting VoIP-compatible firewalls,
IDS and IPS, as well as a session border controller*67 is also an effective preventive measure.

We believe that the growth of VoIP will continue, along with increasingly widespread adoption of personal-use IP phones andcorporate IP-PBXs. On a traditional phone, users would hesitate to answer a call coming in from a complete stranger. This samecaution should apply to both traditional and newly emerging threats involved in VoIP communications.

1.5 Conclusion
This whitepaper has provided a summary of security incidents to which IIJ has responded. In this volume, we have included
security incidents in which IIJ was not directly involved, mainly addressing the DDoS attacks in the United States and South

Korea. We believe that our mission encompasses the collection and analysis of information stemming from incidents that occur
in other countries to be better able to rapidly respond should a similar incident occur in Japan in the future.

By identifying and publicizing incidents and associated responses in whitepapers such as this, IIJ will continue to inform thepublic about the dangers of Internet usage, providing the necessary countermeasures to allow the safe and secure use of theInternet.

Authors:
Mamoru Saito
General Manager of the Division of Emergency Response and Clearinghouse for Security Information, IIJ Service Business Department- After working insecurity services development for enterprise customers, Mr. Saito became the representative of the IIJ Group emergency response team, IIJ-SECT in 2001,
participating in FIRST, an international group of CSIRTs. Mr. Saito serves as a steering committee member of several industry groups, including TelecomISAC Japan, Nippon CSIRT Association, Information Security Operation provider Group Japan, and others. In recognition of its close activities with both
domestic and international organizations, the IIJ-SECT was awarded the “commendation from Director-General, Commerce and Information Policy Bureau,
Ministry of Economy, Trade and Industry (CATEGORY - Promotion of Information Security)” at the FY 2009 Informatization Month Opening Ceremony.
Hirohide Tsuchiya (1.2 Incident Summary)
Hirohide Tsuchiya, Hiroshi Suzuki (1.3 Incident Survey)
Hiroshi Suzuki (1.4.1 DDoS Attacks in the United States and South Korea)
Tadaaki Nagao, Yuji Suga (1.4.2 TCP Vulnerability (Sockstress))
Hirohide Tsuchiya (1.4.3 Randomly Arriving SIP Packets)
Division of Emergency Response and Clearinghouse for Security Information, IIJ Service Business Department
Contributors:
Shigeki Ohara System Development Section, System Infrastructure Division, IIJ Service Business Department
Masahiko Kato, Masafumi Negishi Division of Emergency Response and Clearinghouse for Security Information, IIJ Service Business Department*64

For example, an alert issued by the Internet Crime Complaint Center (IC3: an organization involved in combating cyber crime) in cooperation with U.S. law-

*65

The F-Secure blog post “Beware of One-Ring Fraud,” (http://www.f-secure.com/weblog/archives/00001744.html) for example.

*66
*67

Vol.5

enforcement agencies (FBI, etc.) (http://www.ic3.gov/media/2008/081205-2.aspx).

See the following report as one source of information regarding known vulnerabilities and threats. “Survey Report regarding Known SIP Vulnerabilities Version
2.0” by the IPA. (http://www.ipa.go.jp/security/vuln/vuln_SIP.html)(in Japanese).

A device installed at the boundary of the VoIP network. Responsible for controlling necessary ports according to SIP packet content, and for controlling
functions allowing for normal VoIP communications, even in an NAT environment.
November 200917

Infrastructure Security

Internet, and closed IP networks. Because of this, one must consider the fact that the IP-PBX is more susceptible to externalMessaging Technology

2. Messaging Technology

How Do We Discourage Asia from Continuing
to be a Source of Spam?
In this report, we will offer our analysis of trends in the ratio of spam and regional sourcesof spam detected over the period between weeks 27 and 39 of 2009. At the same time,
we will also comment on the results of international activities designed to reduce or
prevent spam, as well as the adoption rates of sender-authentication technologies.

2.1 Introduction
In this report, we have summarized the latest developments with respect to spam, information about anti-spam technologies,
and other activities in which IIJ is deeply engaged. To analyze spam trends, we conducted an analysis of spam from a numberof different angles, based on information obtained through the spam Filter Feature of the IIJ email services. The volume of email

varies depending on the day of the week according to the service under consideration. Accordingly, we have consolidated dataon a weekly basis to better understand the trends revealed in our analysis. Our survey covered the 13 weeks between week 27(June 29 through July 5, 2009)
and week 39 (September 21 through September 27, 2009)—a total of 91 days. Our prior report(%)

100(Vol. 4) marked the first year
since we began publishing the IIR. We will thus also provide a summary of certain data collected

over that span of time.

90

80
We will also cover international
activities related to the adoption of anti-spam measures. The IIJ has been active in international

discussions regarding spam, mainly through the Messaging Anti-Abuse Working Group (MAAWG). We will provide an overview
70of other organizations and activities herein. We will also take another look at sender-authentication technologies, discussing to60
what extent this and other anti-spam
technologies have actually been adopted.
50

08.06.02 07.02 08.02 09.02 10.02 11.02 12.02 09.01.02 02.02 03.02 04.02 05.02 06.02 07.02 08.02 09.02 (Date)

2.2 Spam Trends

In this section, we will report on historical ratios of spam and the results of our analysis concerning spam sources based ontrends detected through IIJ spam filters. Figure 1 shows the last year of data (69 weeks), including the weeks that are the focus
of our survey—weeks 27 through 39, 2009.

(%)
100

90
80
70
60
50
08.06.02

07.02

08.02

09.02

10.02

11.02

12.02

09.01.02

02.02

Figure 1: Spam Ratio Trends

Vol.5

November 2009

18

03.02

04.02

05.02

06.02

07.02

08.02

09.02

(Date)

The ratio of spam averaged 82.2% of all incoming emails over the 91-day period from week 27 to week 39, 2009. This
compares to an 81.6% average in our last survey (weeks 14 through 26, 2009), indicating a slight comparative increase. Week

39 (September 21 through September 27, 2009) had the highest ratio of spam at 86.7%. This week happened to include anextended national holiday, and the associated lower levels of overall email activity likely contributed to this bump in spam ratios.
Given our experience to date, we expect spam to increase during autumn. Accordingly, we will be keeping a close watch on
spam during the upcoming months.

We have noted a recent increase in spam that sends malicious programs as attachments. New variants of these programs are

released at a very high rate. In some instances, anti-virus software has not been able to keep up with the changes. Users musttake greater care before uncompressing or executing file attachments.

2.2.2 Sources of Spam

Figure 2 shows our analysis of regional sources of spam over the period studied.
Brazil (BR) remained at the top of the list as the number one source of spam, accounting for 12.1% of the total. Brazil actually
increased its overall share of this dubious honor by 0.3%. In our opinion, there is a need to investigate the underlying causesthat have made this region a major source of spam, as well as what measures can be introduced to reduce spam originating
there. We noted a slight variance in the ranking of other top regions during the period investigated. The United States (US)continues to remain near the top, but fell in rank to No. 4 at 7.1%, down 4.3% since our last survey. As we reported earlier, theactivities of the U.S. Federal Trade Commission (FTC) and other consumer protection agencies engaged in enforcement may
be responsible for this positive trend.

Both China (CN) at 9.8% and Korea (KR) at 7.2% remain near the top of the list at No. 2 and No. 3, respectively. Combinedwith Vietnam (VN) at No. 6 (5.6%), these countries are the main reason that Asia has experienced growth as a source of spam.
BR

12.1

Vietnam rose rapidly up the ranks from No. 14 in our previous survey, calling for continued close monitoring. Both Vietnam andCN

9.8

Brazil are representative of a global trend—a stronger network infrastructure due to economic growth also sets the stage toKR

7.2

become a growing source of spam. India (IN) has also demonstrated this trend, ranking No. 5 in our survey at 6.0%, nearlyUSunchanged since our last survey.

IN

VN

7.1
6

5.6

Japan ranked No. 9 in this survey at 3.1%, but increased in ranking andPL
percentage
3.8as a source of spam over the previous
survey. We can think of several reasons for this. One factor that stood out was the volume of so-called error emails. Among

those emails originating in Japan determined to be spam, many originated
RU from major
3.2 Japanese Internet Service Providers.
Looking at the transmission source (envelope From) information and transmission
period of these emails, we see that theJP
3.1

majority were error notifications in connection with mail sent to an unknown
TR recipient.
2.9 In other words, the majority of emails
identified as spam coming from Japan were bounces.

Other 21.5%
TH 1.3%CL 1.3%

BR 12.1%

I T 1.9%

AR 2.2%TR 2.9%J P 3.1%
RU 3.2%CN 9.8%

GB
DE

UA

KR 7.2%

CLTH

US 7.1%Other

I N 6.0%
VN 5.6%
PL 3.8%Figure 2: Regional Sources of Spam

Vol.5

November 2009

2IT

RO 2.0%CO 2.1%RO
ES

DE 1.6%

E S 2.0%

2.2

COUA 1.6%
GB 1.7%

AR

19

2.1
2

1.9
1.7
1.6
1.6
1.3
1.3

21.5

Messaging Technology

2.2.1 Spam Ratio Trends

Messaging Technology

This phenomenon occurs when IIJ customer domain names are appropriated illegally as source information for spam. In
general, this type of malicious usage is difficult to prevent on the part of the domain administrator. One countermeasure is the

adoption of sender- authentication technologies on the part of the sender, as offered by IIJ. Performing sender authentication on

the part of the receiver as well is necessary to determine whether the domain indicated in the sender information represents thetrue gateway for the email being sent. In other words, this type of spam can be eliminated by introducing technology that does
not return a bounce message in connection with email that uses an unauthorized domain name in the sender information.

Figure 3 shows trends in the ratio of spam from the top six countries (Brazil, United States, China, Korea, Vietnam, India) andJapan.

At the outset of the period surveyed, Vietnam was ranked lower than Japan as a source of spam. However, the Asian nationrose quickly through the ranks, reaching as high as No. 4 and No. 5 at certain points since August. These bumps pushed
Vietnam higher overall, ranking No. 6 out of the countries surveyed at the end of the period studied.

From Figure 3, we see the seasonal differences in spam volume over time for each regional source. However, the variances
are not necessarily consistent in each country. For example, Korea (KR) was the greatest source of spam in week 34 (the week
beginning August 17, 2009), exceeding 10%. The increase in total spam volume during this week was due to a large volume

of mail sent from the same source (IP address). While Brazil (BR) experienced some fluctuations in volume weekly, looking
solely at the spam coming from that country, we do not see a great variance in the ratio of large-volume spammers or in those

who send just one spam email in a week. Based on the patterns identified here, we see that a single source of a large volumeof spam had a significant impact on the overall volume of spam sent from Korea to Japan. Brazil and other regions have asmall number of high-volume spam sources, leading us to conclude that much of the spam volume is attributable to computers
infected with bots or similar malicious programs.

While we can expect legal measures in different regions to have some positive effect on large-volume spam sources, there arelimits to what can be accomplished legally where there are significant numbers of small-volume sources. We see here that eachregion and source of spam must be treated according to the individual nature of the region and source.

(%)
16

■JP

14

■IN

12

■VN

10

■KR

8

■CN

6

■US

4

■BR

2
0
09.06.29

07.06

07.13

07.20

07.27

08.03

08.10

08.17

08.24

08.31

09.07

09.14

Figure 3: Trends in Sources of Spam

(%)

16

■JP
■IN
■VN
■KR
■CN
■US
■BR

14
12
10
8
6
4
2
0
09.06.29 07.06 07.13 07.20 07.27 08.03 08.10 08.17 08.24 08.31 09.07 09.14 09.21

9 2009.7.6

2009.7.13 2009.7.20 2009.7.27 2009.8.3(Date)

2009.8.10 2009.8.17 2009.8.24 2009.8.31 2009.9.7

2009.9.14 2009.9.21

5 0.123547 0.119078 0.125498 0.132033 0.128986 0.113461 0.102678 0.110205 0.108689 0.094664 0.140901 0.149612

2 0.091372 0.082397 0.079375 0.06931

0.062121 0.05738

3 0.084815 0.090402 0.109799 0.098768 0.09616

0.06909

0.064771 0.051641 0.057327 0.079203 0.062105

0.091583 0.095002 0.103885 0.109362 0.101764 0.113623 0.101416

5 0.063131 0.077975 0.082177 0.067592 0.062982 0.090568 0.102437 0.083495 0.072884 0.077181 0.044387 0.045656
0.036618 0.045352 0.048418 0.053499 0.063308 0.08177

8 0.05686

Vol.5

November 2009

0.055368 0.071927 0.070815 0.071437 0.049031 0.05012

0.062249 0.058076 0.068338 0.062149 0.060767 0.054625 0.06162

20

0.057231 0.06314

0.057591 0.062761

3 0.025941 0.025979 0.030917 0.029362 0.029267 0.027189 0.030754 0.030011 0.031943 0.033412 0.042697 0.038751

09.21(Date)

As we have clearly demonstrated in our analysis, the majority of spam sent to Japan originates outside the country. Asia, inparticular, has the dishonor of being identified by security vendors as being a source of global spam.*1

The Asia Pacific Coalition against Unsolicited Commercial Email (APCAUCE) is a private organization that addresses spamin Asia. The APCAUCE is the Asian arm of the Coalition against Unsolicited Commercial Email (CAUCE), which is basedin North America. This author participated in the 2006 and 2007 APCAUCE meetings, presenting anti-spam initiatives
conducted in Japan. Unfortunately, the APCAUCE has not met since the 2007 symposium in India. Accordingly, several Asia-

based organizations featuring the “Asia Pacific” moniker in their names have come together to sponsor the AP*Retreat*2 (aninformation exchange symposium), held at the same time as the APNIC 28 meeting in Beijing. The APCAUCE, however, did

not participate. The issue of spam is an important topic, and the cooperation of the co-chair of the AP*Retreat allowed theopportunity for presentations regarding the state of anti-spam initiatives in Japan and China.

These types of volunteer-based organizations tend to rely heavily on the efforts of a single organizer, which is perhaps why

such meetings occur only irregularly. With anti-spam measures in Asia representing such an important issue, the Internet
Association Japan has stepped forward to take the lead as the Japanese representative, moving forward with plans to hold ameeting some time next year.

MAAWG is a private global organization that we have discussed in the Internet Topics section of our prior issue (Vol. 4).

Presently, participants mainly come from Europe, the United States, and the author’s home country of Japan. Asia does notprovide many participants. With MAAWG meetings generally held in North America or Europe, it is difficult for professionals inother regions to participate. Accordingly, IIJ believes in the growing need to hold MAAWG meetings in Asia.

The London Action Plan (LAP)*3 is an example of a global organization that works in cooperation with government agencies.
LAP sponsors annual meetings according to an action plan ratified in 2004 for the purpose of promoting the sharing of
information, organizational coordination, and public-private interaction among enforcement authorities. LAP, MAAWG

and the Contact Network of Spam Enforcement Authorities (CNSA) held a joint meeting in 2007. The fifth joint CNSA-LAP
Workshop was held in Lisbon, Portugal from October 7 to October 10, 2009. The Japanese Ministry of Internal Affairs andCommunications is a member of this organization, and participated in the October meeting, along with this author and theJapan Data Communications Association, presenting Japanese initiatives.*4

The LAP symposium included discussions of anti-spam laws and enforcement in different countries, as well as other anti-spam
activities. Representatives from private organizations (including this author) shared information, as did the German “eco” ISP

group and representatives from MAAWG, who discussed their activities in this field. Other presentations discussed how best to
engage in cooperative activities with law enforcement agencies in the future. The FTC of the United States made a presentation
about the circumstances surrounding the Pricewert shutdown, which we discussed in a previous issue of this report.

*1

For example, Asia is responsible for one-third of all spam according to a continent-by-continent survey conducted by Sophos. (http://www.sophos.com/*2

See http://www.apstar.org for an overview of the AP*Retreat symposium.

*3
*4

Vol.5

pressoffice/news/articles/2009/07/dirtydozenq209.html)

LAP: London Action Plan (http://www.londonactionplan.org)

Workshop CNSA-LAP “Spam-Fighting” (http://www.anacom.pt/render.jsp?contentId=962326)

November 200921

Messaging Technology

2.2.3 International Anti-Spam Activities

Messaging Technology

Australia, New Zealand and several other countries in the Asia Pacific region actively participate in the LAP. Participation by

government agencies throughout Asia is relatively high, with participation with from Hong Kong, Taiwan and Malaysia this year.
The Seoul - Melbourne Multilateral Memorandum of Understanding on Cooperation in Countering Spam*5 was signed in 2005,

representing a collection of government agencies in the Asia Pacific region. Symposia have been held in different member

countries. The Ministry of Internal Affairs and Communications represents Japan, with a symposium held in Tokyo in March
2008.

These types of organizations offer government agencies opportunities to share information. While consistent enforcementof the law is of course important, technological measures to fight highly advanced spam technologies, such as botnets,
are also important. The public and private sectors must work effectively in concert, cooperating in both technological andlegal enforcement in the pursuit of new anti-spam measures. Sending spam from Japan has become more difficult with theintroduction of technological tools, such as OP25B (Outbound Port 25 Blocking). This means that spammers are more likely to
set up bases overseas, particularly farther east in Asia. Cooperation among and between government agencies in Asia is an
important step in doing away with large-scale spam.

2.3 Trends in Email Technologies
2.3.1 Adoption of Sender-Authentication Technologies

We have discussed sender-authentication technologies such as DKIM which uses digital signature technology and networkbased SPF/SenderID. We have also offered the results of a WIDE project survey*6 regarding adoption of such technologies,
particularly the adoption of SPF on the part of the sender.

Here, we will discuss the results of our survey regarding the degree of sender-authentication technologies for emails actually

released. IIJ adopted sender authentication technology*7 in 2005, additionally introducing SPF and DKIM in our continuing

pursuit of email safety and security.

Figure 4 shows the ratio of authentication results when email is received in connection with some of the IIJ emails services.
The period subject to this survey was the entire month of September 2009. Of the emails received during this period, 56.2%
indicated “none” as the result of SPF authentication for the domain name indicated in the sender information. This meansthat the domain for 43.8% of email received declared an SPF record. According to a WIDE survey, the declaration rate for “jp”
domains in October 2009 was 36.8%. Our results showed a greater result under a basis of actual volume. Of course, sendertemperror 0.2%
permerror 0.7%

pass 13.5%

passnone 56.2%

softfail 20.8%

softfail

hardfail
neutralnone

hardfail 2.0%
neutral 6.6%

Figure 4: Authentication Results (SPF) for EmailReceived

*5
*6
*7
Vol.5

Seoul-Melbourne Multilateral Memorandum of Understanding on Cooperation in Countering Spam (http://www.sm-mou.org/

Survey Results of the Deployment Ratio of Sender Authentication Technologies published by WIDE (http://member.wide.ad.jp/wg/antispam/stats/index.
html.ja)

IIJ Introduces Sender Authentication Technology (http://www.iij.ad.jp/news/pressrelease/2005/0317.html)
November 200922

permerr

temperrresults from analyzing emails received in Japan indicate a comparatively advanced usage of SPF.

The ratio of email receiving a “pass” as the result of SPF authentication was 13.5%, while the ratio of authentication failure(“softfail” and “hardfail”) was 29.4%. From this result, we can conclude that the volume of email that falsely represents sender
information was greater than the volume of email sent from a legitimate mail server. Where the volume of spam exceeds

80% of all email received, this is a result with which we can be relatively satisfied. SPF requires care in management, as it issusceptible to forwarding problems and other issues related to false positives. But considering the declaration rates and usageof SPF, a certain level of screening through SPF authentication is one method that can be very effective.
Next, let’s look at Figure 5, which addresses DKIM authentication results.
As with our SPF survey, the period studied was the entire month of September 2009. Of all emails received, 0.8% were fromsenders using some type of DKIM. Given the comparative expense of DKIM for the sender compared to SPF, we see that DKIM

has not been embraced on a large scale. However, DKIM offers comparatively fewer false positives than network-based SPF/

SenderID, which is why we expect usage to increase in the future for important email messages. Where both SPF and DKIM
require the incorporation of additional functions, the cost of authentication on the part of the receiver is the same. Accordingly,
we believe that it is important to promote DKIM incorporation in parallel with SPF for authenticating incoming messages.

2.4 Conclusion
Here, we have reported on the ratio of email determined to be spam and the regional distribution of sources of spam under theheading of messaging technology. We have also discussed significant global and Asia Pacific (including Japan) international
cooperatives. These activities serve as an important anti-spam measure, as private and government agencies share information
through various symposia and engage in cooperative initiatives.

IIJ has presented the data and technologies published through the IIR at international conferences, promoting the adoption ofactivities and measures in different locales. We will continue to be active in the promotion of anti-spam measures in a variety
of different settings.

fail 0.1%

none

99.2

fail

0.1

pass
neutral 0.0%

0.7

neutral 0pass 0.7%

none 99.2%

Figure 5: Authentication Results (DKIM) for Email Received

Author:Shuji Sakuraba
Shuji Sakuraba is a Senior Program Manager in the Service Promotion Section of the Messaging Service Division in IIJ Network Service Department. He
is engaged in the research and development of messaging systems. He is involved in various activities in collaboration with external related organizations
for securing a comfortable messaging environment. He is a MAAWG member and JEAG board member. He is a member of the Council for Promotion of
Anti-Spam Measures and administrative group. He is also a member of Internet Association Japan’s Anti-Spam Measures Committee.
Vol.5

November 200923

Messaging Technology

domains for email received include other top level domains (TLD) such as “com” and “net” in addition to “jp.” We believe that theCloud Computing Technology

3. Cloud Computing Technology

Live Migration of Guest Computers Using
the NEMO BS Mobility Function
In order to construct an efficient virtual computing environment, a system for ensuring the availabilityof virtual computers and managing them flexibly is required. In this whitepaper a virtual computer
migration method using NEMO BS technology, which adds a mobility function to IPv6 routers,

is discussed and the results of experiments using this setup are examined. NEMO BS makes it possible
to migrate virtual computers beyond the network segment.

3.1 BackgroundThe capability of individual computers is progressing rapidly as a result of the processing power of computers and technologicaladvances in networks and data stores. Meanwhile, there is also the view that speed improvements for individual computerswill slow down in the future. In recent years cloud technology that treats multiple computers as a single computer resourceis gaining a lot of attention*1*2 as a remedy for this issue. On the other hand, the virtual computing technology that allows asingle computer resource to be partitioned virtually and used as multiple different computers*3 has been studied for many
years. These technologies may appear at a glance to be targeted at different uses, but it is believed that they can supplement

each other and make it possible to utilize computer resources more efficiently. For example, Amazon's EC2*4 service provides

a cloud environment that combines multiple computer resources into a single service, but virtual computer technology isalso used in each individual computer resource. Using units broken down into small virtual computers instead of using large

resource units consisting of individual physical computers enables the efficient and flexible use of computer resources, andconsequently provides convenience in excess of the overhead created by partitioning into virtual computers.

A system for managing virtual computers flexibly is crucial for developing this kind of virtual computing environment. This isdue to the fact that the ability to arrange the necessary amount of virtual computers in the necessary location in accordancewith the requirements of a cloud service contributes to overall performance increases and the efficient use of resources. In thiswhitepaper, systems for relocating virtual computers are focused on, and a technique for migrating running virtual computers
to a different segment (offlink segment) is proposed.

3.2 Live Migration Issues
Currently, a large number of virtual computer technologies are provided at a practical level. Some of these provide functions

for migrating virtual computers from their parent computer (host computer) to another host computer. VMware's VMotion and
Xen's*5 Live Migration are examples of this kind of technology. In this whitepaper, virtual computers that are generated in thehost computer are called guest computers, and the function for migrating running guest computers between host computers
is called live migration. The use of a live migration function makes it possible to migrate running guest computers to anothermachine with very little downtime. However, the functions that are currently provided are restricted to situations in which thesource host computer and destination host computer belong to the same segment.

This restriction is due to the network configuration method provided to guest computers. Host computers and guest computers
do not have an equal relationship. Host computers normally have control over all resources, and allocate part of these resources

to guest computers. When connecting a guest computer to a network, a configuration like the one shown in Figure 1 is used.

*1
*2
*3
*4
*5
Vol.5

Aaron Weiss. Computing in the clouds. netWorker, Vol. 11, No. 4, pp. 16-25, December 2007.

Brian Hayes. Cloud computing. Communications of the ACM, Vol. 51, No. 7, pp. 9-11, July 2008.

Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, et. al. Xen and the Art of Virtualization. In SOSP '03: Proceedings of the Nineteenth ACM Symposium

on Operating Systems Principles, pp. 164-177, ACM, 2003.

Amazon. Amazon Elastic Compute Cloud (Amazon EC2), October 2009. http://aws.amazon.com/ec2/
Citrix, October 2009. http://www.xen.org/
November 200924

switch provided by the host computer. Similarly, a virtual switch is also created between the host computer and the guest

computers when using configuration (b). Unlike configuration (a), under this configuration the host computer also functions as
an upstream router for the guest computers. As Figure 1 clearly shows, the network configuration for the guest computers ishighly dependent on the host computer. When executing live migration, no changes are made to the operating environment of
the guest computer itself. Consequently, it is only possible to carry out live migration using configuration (a). Under configuration(b), the address allocated to the virtual switch differs depending on the location where the host computer is attached. Thismeans that after a guest computer is migrated, communications cannot be continued until the network environment of theguest computer is updated appropriately. The same problem also occurs under configuration (a) if the source and destination
host computers for migration are connected to different segments.

Live migration makes it possible to avoid consolidating virtual computers on a single host computer, but this function is limited
to migration within the same segment. Even if there is a host computer on another segment with free resources, it cannot beutilized. It is also not possible to relocate resources to improve performance, such as migrating a guest computer to a hostcomputer that is closer to the user.

3.3 Overview of NEMO BS
NEMO BS (Network Mobility Basic Support)*6 is a protocol for adding a mobility function to IPv6 routers. In a NEMO BS
environment, a MR (mobile router) compatible with NEMO BS manages the MNP (mobile network prefixes) that serve as fixed

network prefixes. IPv6 hosts connected to the network provided by the MR use fixed addresses in the MNP range. The MR

connects to various segments over the Internet, and maintains connectivity with the Internet according to the target network
environment. During this the MNP the MR manages does not change. Hosts attached to the network controlled by the MR are
always able to maintain the same network environment regardless of the location of the MR.

This function is achieved with the support of the HA (home agent) that serves as a counterpart to the MR (Figure 2). The MR

acquires an address (care-of address) on the destination network depending on the network environment, and establishes abidirectional IPv6 over IPv6 tunnel with the HA. Traffic originating from nodes within the MNP is sent to the HA using this tunnel,
then transmitted from the HA to the target of communications. Meanwhile, traffic directed to nodes within the MNP is received
by the HA, delivered to the MR via the tunnel, then transmitted to the final destination host.

Host computer physical interfaces
Host computer and guest computer virtual interfaces

MNP

MR/MNP
Logical Location
MNP

Host Computer

Host Computer

Virtual Ethernet Switch

HA

NAT orRouting Module

MR/MNP
Actual Location

MR

Virtual Ethernet Switch
Guest
Computer

Guest
Computer

Guest
Computer(a) Host computer and guest computers
use bridge connection

Guest
Computer

Guest
Computer

IPv6 over
IPv6 Tunnel

Guest
ComputerTarget ofCommunications(b) Guest computers use routing or NAT module
provided by the host computer

Communications Path for
Hosts Under MR’s MNPFigure 2: Operational Overview of NEMO BS

Figure 1: Guest Computer Network Configurations*6

Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert. Network Mobility (NEMO) Basic Support Protocol. IETF, January 2005.

Vol.5

November 2009

RFC3963

25

Cloud Computing Technology

Using configuration (a) in Figure 1, the guest computers are connected to the same network as the host computer via a virtual

Cloud Computing Technology

3.4 Design
Live migration is limited to migration within the same segment because the network environment for guest computers isdependent on the host computer. In other words, if the guest computer's network environment is designed so that it is fixedand does not depend on the host computer, it will be possible to migrate guest computers to host computers connected todifferent segments.

In this whitepaper, a method for using IP mobility technology to maintain a fixed network environment on guest computers is
proposed. There are two approaches to this: equipping the guest computers with a host mobility function such as Mobile IP*7*8,

and utilizing a system such as NEMO BS on the host computer to provide a fixed network for guest computers. The former
option requires the modification to guest computers (the installation of an IP mobility function), but this makes the migration ofindividual guest computers possible, allowing for finer control over computer resources. The latter option allows existing guest

computers to be used without any modifications, but requires that the migration of guest computers and the migration of thehost computer serving as the MR for NEMO BS be synchronized. In this whitepaper the latter option is focused on, assuming
a scenario where the guest computers used in an existing system will continue to be utilized.

The system design may differ depending on the resource management method for host computers. In this whitepaper a designusing the virtual computing environment provided by Xen is discussed, but it should be possible to apply a similar design toother systems without significant changes. Figure 3 shows an overview of this design. The configuration used is an expanded

version of (b) from Figure 1. The host computer functions as the MR, providing two interfaces, one is for connecting to theInternet and the other is for providing MNP. The MNP connection interface is a virtual interface rather than a physical interface.
This virtual interface is connected to the virtual switch that the host computer provides for guest computers. The host computer's
virtual interface and the interfaces for guest computers connected to the virtual switch are allocated fixed addresses managed

by the MR. Through the NEMO BS function, addresses within MNP do not change regardless of where the host computer isphysically connected.

In the proposed environment for live migration of guest computers, multiple host computers are located on the network. Thesehost computers act as MR and are configured with the same MNP, but host computers that have no active guest computers do

not function as an MR. When migrating guest computers, regular live migration procedures are first performed to migrate guest

computers to the destination host computer. At this point, guest computers are still disconnected from the network. Following
this, the source host computer sends a migration complete notification to the destination host computer, and suspends its

NEMO BS function. The host computer that receives the migration complete notification registers its location with the HA, andbegins operation as a NEMO BS MR. Once registration with the HA is complete, the MNP for the virtual switch that the guest
computers are connected to is activated, and migration is complete.
HA(Home Agent)Internet

Host ComputerMR(Mobile Router)

MNP Fixed
Address Space

Host Computer
NEMO BS
ModuleNEMO BS
ModuleVirtual Ethernet Switch

Guest
Computer

Guest
Computer

Virtual Ethernet Switch

Figure 3: Guest Computer Migration Using
NEMO BS

Guest
Computer*7

Basavaraj Patil, Phil Roberts, and Charles E. Perkins. IP Mobility Support for IPv4. IETF, August 2002. RFC3344

Vol.5

November 2009*8

David B. Johnson, Charles E. Perkins, and Jari Arkko. Mobility Support in IPv6. IETF, June 2004. RFC3775.

26

To confirm that the proposed design is feasible, a prototype system was implemented and operation experiments were

performed. The experiment environment was configured with a total of five computers: two Xen host computers operating as
MR, a computer with HA function, a computer for receiving streaming data during testing, and a control computer for initiating

migration operations. A guest computer was created with the Xen host computers and configured to operate as a streaming
server.

In order to carry out experiments in an environment close to real conditions, this equipment was placed into an actual Internet

environment. The fixed network for the HA and MR to use was installed as a part of the network constructed for Interop Tokyo
2009*9, and the Xen host computers and stream data reception nodes were placed on the IIJ network. Each piece of equipment

was connected to the others via the Internet. Figure 4 shows an overview of the experiment network.

15 MB, 520 KB/s MPEG4 stream data was continually sent from the guest computer (the streaming server) using UDP. The

instructions to begin live migration of the guest computer, and the suspension and initiation of the host computer NEMO BS
function were carried out over SSH using a separate control computer. The guest computer live migration command was

executed remotely from the control computer, and host computer NEMO BS movement processing was executed immediately

after live migration was complete. The guest computer was repeatedly migrated between the two host computers every fiveminutes.

NEMO BS HA(Home Agent)Control Computerfor Migration

Stream Data
Reception Node
NEMO BSIPv6-in-IPv6 TunnelInterop Tokyo 2009
Network

Xen Host Computer 1+
Mobile Router

Xen Virtual NEMO Network
for Guest Computer

Xen
DomainInternet

Shared Storage for
Guest Computer

Guest Computer(Streaming Server)

Interop Tokyo 2009, June 2009. http://www.interop.jp/

Vol.5

November 2009

Xen Virtual NEMO Network
for Guest Computer

Guest Computer(Streaming Server)

Figure 4: Experiment Network Overview*9

Xen Host Computer 2+
Mobile Router

27

Xen
DomainCloud Computing Technology

3.5 Verification Tests

Cloud Computing Technology

3.6 Evaluation and Issues
Figure 5 shows the results of monitored stream traffic over the host computer's Internet interface. Live migration of the guest

computer was carried out every five minutes, and migration between the two host computers can be seen as a movement of
the traffic between two host computers.

When using live migration, the source virtual computer continues operation while virtual computer data is being copied to thedestination host computer. The downtime when operation is switched over is quite small (about several hundred milliseconds).
However, as network layer mobility technology was used to migrate the host computer in this proposed mechanism, node
movement processing was also necessary for the host computer after the guest computer was migrated. When examining thetraffic data details, it became apparent that it was taking approximately six seconds for the destination host computer to begin
sending streaming data after the source host computer had suspended the distribution of streaming data.

As router advertisement messages on the network where the host computers connect were made at three to four second

intervals, the host computers were in an environment where they could receive router advertisement messages in about two
seconds. Even when the one second care-of address duplicate confirmation that is a part of NEMO BS processing is taken into

account, movement processing should be completed in approximately three seconds in this environment. The following two
points are possible reasons for processing taking longer than this in the experiment.

1. Overhead due to the execution of the remote control script from the control computer.
2. Procedures that differ from regular movement processing procedures.

Xen Server 1: IPv6 UDP streaming traffic

As the suspension and initiation of the NEMO BS function■Throughput■Tread (30 min)were executed using a remote script via SSH, more timethan usual was required for actions such as TCP connection
establishment, process generation on the host computer,and controlling the NEMO BS daemon program via remotecommand. Additionally, movement processing that would
normally be executed on a single mobile node was jointly

executed on two different mobile nodes in the proposed

Xen Server 2: IPv6 UDP streaming traffic

mechanism. In other words, one MR executed registration
processing after the other MR finished cancelling registration

with the HA. When carrying out movement processing using

the same MR, there is no need to cancel registration of old
information when registering new information, so updates

are made consecutively. In the proposed mechanism extra
time was required for canceling registration.

Figure 5: Stream Traffic Transition

3.7 Consideration
The prototype implementation and experiments aimed at verifying the combination of two technologies (NEMO BS and Xen
virtualization). This section mentions some observations found during the experiments.

3.7.1 Network Storage Issues

There are two methods of providing storage for guest computers under systems that offer a virtual computing environment, one isproviding part of the host computer's storage, and the other is providing network storage. Storage must be located on the network

when using live migration, as the host computer that accommodates guest computers will change. As guest computers are notmigrated beyond the same segment under current assumed usage patterns, there are no significant changes to the environment
before or after migration even when network storage is used. However, when migrating guest computers beyond their segment as
in the proposed mechanism, there is the possibility that network storage reachability and communication delay issues may occur.

Vol.5

November 200928

external storage. However, under this method increases in the amount of data to be stored in memory will cause migration totake longer to complete. This construction also makes it difficult to handle large amounts of data.

Another method is to provide storage that can be handled efficiently and transparently from multiple locations on the Internet.
For example, developing storage mirroring technology and making it possible to access the same storage data from multiple
locations should ease the network quality changes to guest computers and also allow for improvements to be made to thefault-tolerance of storage.

3.7.2 Usability Issues

In the proposed mechanism the NEMO BS technology is used, but there are two issues with this method.
First, there is the fact that tunnel communications via HA is a prerequisite, although the same is true for all Mobile IP-based
mobility technologies in general, and not just NEMO BS. This creates new issues to be considered, such as the HA becoming asingle point of failure, and the need to introduce redundancy technology into the HA. It may be possible to resolve these issues

by adopting different mobility technology that does not use tunneling, such as HIP*10, LIN6*11, or MAT*12. To achieve the offlink

live migration of virtual computers, the primary requirement is to maintain the network environment of the virtual switch that
virtual computers connect to. Consequently, the method used to achieve this does not need to be NEMO BS.

The second issue is that by using NEMO BS, all guest computers are managed as a cluster of nodes attached to the same

fixed network. This means that when a host computer is migrated, all related guest computers must also be migrated at thesame time. This issue can be dealt with using one of the following methods. One method is to have guest computers adopt
a host-based mobility technology, for example Mobile IP. In this case all guest computers must support Mobile IP, increasing

the requirements for deployment. NEMO BS has the large advantage of it not being necessary to modify guest computers, so
standard guest computers can be used as-is. Providing a NEMO BS environment implemented as a virtual computer for each

guest computer would be a compromise for this. This would operate as a kind of Mobile IP proxy. This method would make itpossible to migrate individual guest computers while avoiding the need to make any changes to them.

3.8 Conclusion
Ensuring the mobility of computer resources will be crucial in the cloud computing environments of the future. Virtual computer

live migration technology is a strong candidate for ensuring resource mobility. However, using current live migration technology

the migration destination is restricted to other host computers within the same segment. This is because the network environment

provided to guest computers is dependent on the physical network that host computers connect to. If this restriction could be removed

and migration to other remote segments were made possible, it would allow for more flexible management of computer resources.
In this whitepaper a technique for migrating guest computers between multiple host computers that do not share a segment using

virtualization and NEMO BS technologies is proposed. The use of NEMO BS technology to provide guest computers with a fixed
network environment regardless of the network a host computer connects to makes cross-segment migration possible.

In closing, while conducting this research I received a great deal of advice regarding Linux and MIPL/NEPL configurations from

Masahide Nakamura, Jean Lorchat, and Martin André. I would also like to thank Takashi Miyake, Manabu Ori, and the Interop
Tokyo 2009 NOC team for their assistance in preparing the test environment.

Author:Keiichi Shima
IIJ Innovation Institute Inc. Research Laboratory
Mr. Shima is pursuing the research and development of IP mobility technology that will be necessary for transitioning continually evolving Internet terminals
to wireless systems.

*10
*11
*12

Vol.5

Robert Moskowitz, Pekka Nikander, Petri Jokela, and Thomas R. Henderson. Host Identity Protocol. IETF, April 2008. RFC5201

Mitsunobu Kunishi, Masahiro Ishiyama, Keisuke Uehara, Hiroshi Esaki, and Fumio Teraoka. LIN6: A New Approach to Mobility Support in IPv6. In Wireless
Personal Multimedia Communication (WPMC), November 2000.

Reiji Aibara, Takahiro Fujita, Kaori Maeda, and Yoshihiro Nomura. Mobile Internet Architecture with Address Translation. Special Issue on Next Generation
Mobile Communication Networks and their Applications. IPSJ Journal Vol. 43, No. 12, pp. 3889-3897, December 2002.
November 2009

29

Cloud Computing Technology

One solution to this is constructing a guest computer environment that carries out all processing in memory without usingService Infrastructure

4. Service Infrastructure

The Design and Implementation of the NHN
Next Generation Service Infrastructure Using Virtualization
Technology and Remote Data Centers
NHN (Next Host Network) is IIJ's next generation service infrastructure.

When NHN is adopted, service development flow and demand forecasts forequipment upgrades at IIJ are set to change dramatically. Here, we provide an overview of NHN,
its technological components, architecture and implementation.

At IIJ we have implemented a service infrastructure that provides flexibility, while keeping data center costs low through theutilization of remote data centers. We designed the "NHN" (Next Host Network) in 2008, with the aim of consolidating onsite

work in one place, devising systems for the efficient use of rack space and electricity, and reducing the operating costs.
It was prepared as an infrastructure for the migration of both new and existing services. In this whitepaper we explain thecircumstances leading up to the introduction of NHN, its technological components, architecture and implementation.

4.1 Background to Adoption of NHN
IIJ has until now operated over 200 racks and several thousand servers distributed over multiple data centers for use in our own

services. As equipment was constructed with each host reserving a rack for individual services, the rack space and network
devices were designed with headroom to cope with future increases in demand, resulting in lost potential for the infrastructure

as a whole. Using a system configuration such as this that is vertically segmented for each service makes it difficult to expand
when plans change and also reuse equipment when a service is discontinued. Service infrastructure costs piled up, and as
racks used different equipment and cabling, the complexity of operation had also become an issue.

Until now we had taken factors such as support when a failure occurs into consideration, and used a data center with afavorable location in Tokyo because of the ease of access to a physical system, aiming for optimal server operation. However,with the improvement in performance and lower costs of IA servers over the past few years, and power consumption for eachserver continuing to rise, facility costs such as rack space, air conditioning costs for cooling, and power costs now make up ahigher percentage of the total than equipment costs such as networks, servers, and storage. Our Tokyo data center receives

a lot of business from customers, and even when there was space to install equipment, we were not able to install enoughservers due to limitations such as a shortage in our capacity for cooling, UPS, and emergency generators.

As we saw that a configuration with systems concentrated at the Tokyo data center was reaching its limit, IIJ decided to
drastically reduce costs by moving service equipment that was not dependant on location to a low-cost facility on the outskirtsof Tokyo. We considered all options that would lead to reduced facility costs and power requirements, such as container-type
data centers. Advances in multiplexing technology have made it possible to keep network costs down, and this also motivatedour plan to move to a data center out of central Tokyo.

While considering our options, we also moved ahead with transitioning to a configuration that ensures freedom and mobility ofoperations even when a remote data center is used.

Moving service equipment to a data center away from the city reduces space costs, personnel expenses, and power costs,

leading to cost reductions across the entire service infrastructure. We began looking into NHN with the goal of improving
operational freedom at the same time.

Vol.5

November 200930

For NHN, we isolated the following points that must be given priority and points that could be put on hold, based on our
experience as a server operator.

● Regarding storage, foreseeable failures such as individual HDD failures are acceptable. However, there is a need to designa configuration with high reliability to prevent failures that lead to service outages.

● Server devices sometimes fail. As there are wide-ranging points of failure, and there is a limit to how much the failure rate canbe curtailed, a configuration that suffers little impact when a failure occurs is ideal.

● Failures of network devices used on the edge are not very common in our experience to date. NIC redundancy settings, etc.,
are only implemented when required.

Next, we will detail the failure rate of devices that IIJ uses, and explain the sequence of events that lead to the plan mentioned
above.

4.2.1 Storage Failure Rates at IIJYear

HDD Failures

HDD Failures in the Same RAIDDAS*1 that IIJ uses, we confirmed that despite the number

2005

32

7 x 1 unit, 5 x 1 unit, 4 x 1 unit, *2
2 x 2 units, 1 x 12 units

dropped over the past few years. Another trend in the

2006

22

2 x 3 units, 1 x 16 units

2007

16

2 x 1 unit, 1 x 14 units

2008

7

2 x 2 units, 1 x 3 units

2009

4

1 x 4 units (as of September 2009)

After investigating the logs for the approximately 100

of storage units changing very little, HDD failure rates hadlast few years is that almost no correlation was observed

between storage load and failure rates. It seems that HDD
failures occur regardless of load, and it is rare for failuresto occur more often in HDDs in a certain storage unit.

As the HDD failure rate is dropping each year, storage failures other than HDD failure, and in particular those that lead directly toservice outages, have become more conspicuous. Specifically, this refers to failures such as the following.
● Suspension of function due to the failure of cache memory on a RAID controller● Unstable operation thought to be caused by a RAID controller failure● Failure of connection interfaces on SCSI cards, etc.

● Performance degradation due to the failure of a battery backup unit on a RAID controller or it reaching its lifespan
Failure numbers amount to a few times per year overall, but when failures such as those above occur in devices without RAID

controller or connection path redundancy, it is not possible to restore operation until the device is replaced onsite, leading directly

to a service outage. When considering a remote data center option, we decided that for storage service outages it would take anunacceptably long time to complete the replacement of a device. For this reason, we made RAID controller and connection path
redundancy a requirement when selecting devices, although this would make hardware costs higher than at present.

4.2.2 Server Failure Rates at IIJ

Regarding server failure rates, servers are often replaced on the spot as a precaution to prioritize the restoration of service,
and in some cases the symptoms cannot be recreated after the device that has failed is subsequently taken back and tested,meaning that there is no statistical information regarding the parts that have failed.

We estimate that the failure rate is approximately 1-2%, based on the number of servers that were repaired in the six months
between April and September 2009, and the number of servers that were switched out and are awaiting inspection. However,this figure does not include failures in redundant parts, such as the failure of one of a pair of redundant HDDs. For this reason,
we estimate that a significant number of server devices fail.

*1

An abbreviation of Direct Attached Storage. At IIJ we chiefly used devices that connect externally via SCSI I/F until 2008. HDD failures for setups where a local*2

As the devices for which 7, 5, and 4 units failed in the same RAID in 2005 were the same product type and were installed in the same period, it is highly likely

Vol.5

HDD is added to a server are not included.

they were part of a faulty batch. We removed them from service use in 2005.
November 200931

Service Infrastructure

4.2 A Design Plan Optimized Remote Data Center

Service Infrastructure

Stoppages caused by memory failures and reboots stand out as reasons for failures. There were a wide range of other reasons

such as thermal runaway due to fan failure, backplane failures in connectors for devices such as HDDs, power (VRM) failures,and processor failures.

When a failure to boot occurs in a server device fitted with a local HDD, it is necessary to carry out repairs onsite to relocate

the HDD from the failed equipment into working server equipment. A great deal of personnel expenses are incurred in order tohave operators who can perform server device maintenance such as that mentioned above on duty 24/7 at a data center. Whenconsidering a remote data center, costs will increase if operators are on duty 24/7, but if operators are not on the premises itwill take a great deal of time to restore service. For this reason, we made diskless operation in which servers have no local dataa prerequisite when selecting devices.

4.2.3 Network Device Failure Rates at IIJ

Failure numbers for edge L2 switches that accommodate hosts, etc. are not high in our experience to date. Excluding cases thatinvolve specific faulty batches such as faulty condensers, the figure is less than 1% of the units in operation.

It is also possible to adopt a redundancy configuration using NIC redundancy settings, but this makes the addition of NIC andnetwork devices necessary, increasing costs. Additionally, as adopting a redundant configuration over servers using devices
such as a load balancer usually makes operation easier, we went with a design implementing NIC redundancy settings only

when higher reliability was necessary, and did not add redundancy to switches accommodating the servers for the basic
configuration. Also, to limit the impact of edge L2 switch failures, we designed a system that made it possible to either form aredundant configuration with devices under the control of other server switches using a load balancer, or deal with failures by
migrating the contents of server devices controlled by the faulty server switch to a server under the control of another serverswitch using remote control.

4.3 NHN Configuration
For NHN, we used the following configuration that also supports remote data centers.
● A server pool system is used and large numbers of servers with identical specifications are installed. Onsite work
such as device installation and the physical replacement of failed devices can be consolidated into monthly scheduled
maintenance.

● Server configuration is standardized and no modifications are made to physical configurations such as changes to theamount of physical memory installed or the installation of a local HDD, in order to curb configuration management costs.

● Energy-saving servers are used to increase the number of servers that each rack can accommodate.

● Racks are not assigned to specific services to increase the number of servers that each rack can accommodate.

● Devices and cabling are standardized to reduce the possibility of mistakes when device installation or replacement work is
outsourced on a case-by-case basis.

● Consolidation and degree of freedom is raised through combination with virtualization technologies such as Xen and
OpenVZ.

● VLAN is used to make it possible to configure a logical network without changing onsite cabling.

● iSCSI is used to configure a cheap SAN. RAID controller and connection path redundancy are required for storage to prevent
service outages as far as possible.

● It is assumed that diskless servers will break down. The goal is to make it possible to complete temporary restoration byswitching over devices remotely when a hardware failure occurs.

● If the time it would take for switchover to a backup server to be completed when a failure occurs in a diskless server results
in a longer service outage than is acceptable, two servers from separate groups are prepared in advance and a device suchas a load balancer is used to create a redundant configuration, making an application-based redundancy configuration
possible.

● All work that is required after installation, including OS installation, can be executed remotely.
Next, we explain each technological component.

Vol.5

November 200932

When use in a remote data center is taken into consideration, the service downtime of storage can lead to extended failures,

so we sought even higher storage reliability than we had in the past. IIJ has introduced a system using iSCSI, as it excels at IP
network technology, and it makes it possible to put together cheaper systems than FC SAN. Also, by making RAID controller

and connection path redundancy a requirement, we have reduced the risk of storage failure that may render our services
inaccessible to a minimum.

4.3.2 Implementing a Diskless Server Combining iSCSI Storage and Energy-Saving Servers

Few current server devices support iSCSI boot, and installing iSCSI HBA on all server devices is costly. Because of this, we devised
a way to make SAN boot with iSCSI possible using PXE boot, which is supported by the onboard NIC of most server devices.

Information such as the iqn*3 and IP address that is necessary for iSCSI boot is passed on using DHCP options. This makes it possible
to replace a failed server device with a backup device by overwriting configuration information and booting the backup server.
To Upstream Network

Physical Network Configuration of NHN
PrimaryServer Pool

↑Service Network↑
Server Switch

SecondaryServer Pool
1Gbps

1Gbps

Storage Pool
1Gbps

1Gbps

Server Switch

1Gbps

Server

1Gbps

Server

10Gbps

10GbpsServer Switch
10Gbps↓Storage Network↓

10Gbps

10Gbps

10Gbps

10GbpsSecondaryPrimary

Configuration Management Server,
PXE Server, etc.

①②③

Figure 1: Physical Configuration of NHN①②③

PXE Server(+dhcpd)

PXE Server(+dhcpd)

Initiator(Diskless)④④
iSCSI Target⑤

Initiator(Diskless)

Initiator(Diskless)…

1. Address and parameters are acquired using DHCP.

iSCSI Target

2. Kernel and initrd images are acquired from TFTP.

⑤

3. Kernel is booted in an initrd ramfs root environment.
4. iSCSI initiator is initialized based on DHCP parameters (visible as a local HDD).

Initiator(Diskless)

Initiator(Diskless)

Initiator(Diskless)

5. This is mounted as a block device, and switchroot is used to switch tothe mounted location.

…

Figure2: DisklessServer(Linux)Boot using PXE boot and iSCSI
1. Address
and parameters
are acquired
using DHCP.
2. Kernel and initrd images are acquired from TFTP.

*3

3. Kernel is booted in an initrd ramfs root environment.

An abbreviation of iSCSI Qualified Name. Here this is used for the unique identification of iSCSI targets.

4. iSCSI initiator is initialized based on DHCP parameters (visible as a local HDD).
5. This is mounted as a block device, and switchroot is used to switch tomounted location.
Vol.5 theNovember
2009

33

Service Infrastructure

4.3.1 Adoption of iSCSI-based IP SAN

Service Infrastructure

To avoid the need for onsite work in the event of a server failure, for NHN we used a diskless configuration for servers so they
have no local data. If a failure occurs in one server device, it is possible to boot backup servers that are already in place whilestill maintaining the storage content of the failed device by overwriting configuration information remotely and rebooting.

4.3.3 Implementing a Virtual Network That Requires No Cabling Changes Using VLANFor NHN, we rendered onsite cabling changes unnecessary by having multiple networks coexist over a single physical cable,

making all maintenance possible remotely. Technically, each server is configured as a network using access VLAN and trunk
VLAN, with multiple networks made to coexist over a single physical cable as necessary.

VLAN is not a new technology, but for NHN we implemented a system that made it possible to link it with the configuration
information that IIJ manages, and automatically overwrite the VLAN settings of a server switch that accommodates a given
host. This reduces VLAN setting errors in network devices, and cuts operating costs.

4.4 Results of Adoption of NHN
IIJ began looking at its future use of remote data centers in 2008, implementing drastic revisions to service host configurations
under the keyword "NHN," and preparing an infrastructure for the migration of new and existing services.

We adopted new technology for NHN based on our perspective and experience as server operators, introducing virtualization,
diskless servers using iSCSI, the centralized management of host information, and dynamic updates for network device VLAN
settings.

When we adopted NHN for our internal system, the differences with previous service host configurations were not immediately
apparent, and opinions such as the following were sometimes heard.
●I don't trust virtual servers. I'd rather use physical servers.

●This level of performance is not necessary, so I want cheaper servers.
●There is too much memory, so I'd like it reduced.
●Disk unit prices are higher than local disks.

Opinions such as these were heard at first, but even though individual servers have slightly higher prices, people understoodthe cost benefits when taking into account factors such as consolidation, facilities, and operating costs after the introduction ofvirtualization, and currently there is less resistance to in-house introduction.

Additionally, people are beginning to see the merits of servers that can be ready to use a few days after being requested, andcan be returned when no longer required without requiring any physical work to be carried out at the data center. Because

until now equipment was constructed using different devices for each service, it was difficult to reuse devices in other services
when plans changed, and when devices were required urgently there was a delay before they could be used while waiting fortheir purchase and installation to be completed. Due to the introduction of NHN, service development flow and the system formaking demand forecasts for equipment upgrades are gradually changing.

IIJ will continue investigating the security and I/O virtualization aspects of this technology, and polish it for eventual release to
IIJ GIO and other customers.

Authors:
Yasumitsu Makino
Section Chief, System Operating Section, System Infrastructure Division, IIJ Service Business Department
Mr. Makino is engaged in the design and operation of server infrastructure for corporate and private services. Since 2008 he has consolidated equipment
procurement and onsite construction work for service hosts at the System Operating Section, and worked towards optimizing the consolidation andoperation of equipment through infrastructure systemization.
Shinya Hanataka
System Operating Section, System Infrastructure Division, IIJ Service Business Department
Tadashi Kobayashi
System Operating Section, System Infrastructure Division, IIJ Service Business Department
Vol.5

November 200934

Here, we introduce the anti-Malware engineering WorkShop 2009 (MWS2009), which was held at the Toyama International ConferenceCenter over three days from October 26, 2009*1. This is a research workshop for malware analysis sponsored by the Information
Processing Society of Japan and the Cyber Clean Center Steering Committee. This is the second time the workshop has been held,
following on from MWS2008*2 last year, and this year over 100 researchers, students, and corporate engineers actively participatedin presentations and discussions. The workshop involved creating CCC DATAset2009 for common analysis from malware activity
information (malware specimens and communications data) acquired at the Cyber Clean Center*3, and sharing the achievements ofresearch into technology for analyzing and producing countermeasures by utilizing this data set*4.

■ CCC DATAset2009
Presenters are provided with the following three types of data as CCC DATAset2009.
●Malware specimen data
Hash values for 10 malware specimen varieties (researchers must obtain malware specimens themselves). Analysis results are also
provided at a later date.
●Attack communications data
Two day's worth of communications data from two honeypots (CCC DATAset2009 uses data from March 13 to 14, 2009). A packet dump
showing actual communications is provided.
●Attack origin data
A year's worth of attack communications records from 94 honeypots (CCC DATAset2009 uses data from May 1, 2008 to April 30, 2009).
This includes the time, the source IP address of the attack origin, the destination port number, and the name of malware.
CCC DATAset2009 content has been expanded beyond that of CCC DATAset2008*5. Presenters can verify the effectiveness of theirresearch results using actual observed data by applying them to one of these data sets.

■ MWS2009
Last year there were 22 general oral presentations (including 8 given by students), and for MWS2009 this number rose to 30 (including
15 given by students). Presentations covered a wide range of topics, from methods for carrying out efficient malware analysis, totechniques for improving honeypots, techniques for visualizing malware activity, and attempts at predicting this activity*6. As indicatedby the number of presentations given by students, another feature of this year’s workshop was the more active role played by students.
At IIJ we compared CCC DATAset2009 attack origin data with observed data from the MITF honeypots that we operate ourselves, andpresented a big-picture look at differences in the observed results. We believe that by comparing multiple observed results for the same
period we can help fuel discussions regarding the locality of events and the accuracy of observation techniques.
The MWS Cup 2009 event was also held for the first time at this workshop. In this event participants vied for the best analysis technology
by analyzing malware activity record data they were given as a task within a set time limit. Participants brought tools they had created aspart of their research as well as the analysis environment they use on a daily basis, and competed to analyze data handed out on CD on
the day of the event as quickly and accurately as possible. Seven teams participated despite this being the first time the event was held,
and once again students did remarkably well, with university teams reaching the top ranks.
The anti-Malware engineering WorkShop can be thought of as an effective venue for comparing research results in a fair way throughthe analysis of common data, and a place for developing human resources that have expertise inmeasures against malware in the future. IIJ also considers it an invaluable occasion for interactingwith the academic community that we seldom have the opportunity to exchange opinions with,and we would like to continue to actively participate in this workshop in the future.
Author:Mamoru Saito
General Manager of the Division of Emergency Response and Clearinghouse for
Security Information, IIJ Service Business Department*1

The MWS Cup 2009 event

Anti-Malware engineering WorkShop 2009 (http://www.iwsec.org/mws/2009/)(in Japanese). Held concurrently with the Computer Security
Symposium 2009 (CSS2009) (http://www.iwsec.org/css/2009/english/index.html) sponsored by the Computer Security (CSEC) Group of theInformation Processing Society of Japan. Photos of MWS2009 can be viewed on the MWS2009 activity archive (http://www.iwsec.org/mws/2009/
*2
*3
*4

*5
*6

Vol.5

photo.html)(in Japanese).

IIJ also attended MWS2008 held last year. MWS2008 (http://www.iwsec.org/mws/2008/)(in Japanese). This workshop was discussed in aconversation published in IIJ.news Vol.90 (http://www.iij.ad.jp/news/iijnews/2009/vol90.html)(in Japanese).

The Cyber Clean Center is an anti-bot measures project coordinated by the Ministry of Internal Affairs and Communications, the Ministry of
Economy, Trade and Industry, and other related organizations (https://www.ccc.go.jp/en_index.html).

Other endeavors involving the sharing of research results based on common data include the DARPA Intrusion Detection Data Sets (1998,

1999) (http://www.ll.mit.edu/mission/communications/ist/corpora/ideval/data/index.html) and the Knowledge Discovery and Data Mining Tools
Competition (http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html).

CCC DATAset 2008 consisted of one variety of malware specimen data, two day's worth of attack communications data, and six month's worth of
attack origin data respectively.

MWS2009 papers and presentations for which the author's consent has been received will be published on the following site (http://www.iwsec.
org/mws/2009/)(in Japanese).

November 2009

35

Internet Topics

Internet Topics: About the anti-Malware engineering WorkShop 2009

Vol.5 November 2009

About Internet Initiative Japan Inc. (IIJ)
IIJ was established in 1992, mainly by a group ofengineers who had been involved in research anddevelopment activities related to the Internet, under
the concept of promoting the widespread use of theInternet in Japan.
IIJ currently operates one of the largest Internet
backbones in Japan, manages Internet infrastructures,and provides comprehensive high-quality system
environments (including Internet access, systems
integration, and outsourcing services, etc.) to highend business users including the government andother public offices and financial institutions.
In addition, IIJ actively shares knowledge
accumulated through service development andInternet backbone operation, and is making efforts to
expand the Internet used as a social infrastructure.

The copyright of this document remiains in Internet Initiative Japan Inc.

(“IIJ”) and the document is protected under the Copyright Law of Japanand treaty provisions. You are prohibited to reproduce, modify, or make thepublic transmission of or otherwise whole or a part of this document without
IIJ’s prior written permission. Although the content of this document is paid

Internet Initiative Japan Inc.

Address: Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku, Tokyo, 101-0051
Email: info@iij.ad.jp URL: http://www.iij.ad.jp/

careful attention to, IIJ does not warrant the accuracy and usefulness of
the information in this document.

©2008-2009 Internet Initiative Japan Inc. All rights reserved.

IIJ-MKTG020CA-0912CP-00001PR