Network Security Incident Analysis System for Detecting Large-scale Internet Attacks

Network Security Incident

Analysis System for Detecting

Large-scale Internet Attacks

Dr. Kenji Rikitake

Security Advancement Group NICT, Japan

Our goals

• Collaborative monitoring, centralized

network security incident analysis and

handling among Japanese Internet

Service Providers (ISPs), including:

– real-time analysis for early-warning trends – in-depth analysis for detecting new threats – recommendation to the ISPs and users

Our partners

• Telecom-ISAC Japan

– Wide-area monitoring with probes on ISPs – Incident handling with contingency plans – Clearing house of incident info for ISPs

• Internet Security research communities

– Academic network administrators – Virus and malware analysis experts – Datamining and statistics experts

Our project and Telecom-ISAC

ISPs probes probes probes Honeypot networks Blackhole networks

Academic network probes Traffic statistics from partner ISPs and networks Real-time analysis

system (of primary short-term statistic analysis and incident detection)

Integrated database for analyzed data and incidents In-depth analysis system (for long-term and detailed analysis with human experts)

Analysis experts Telecom-ISAC Japan Operation Center

Incident-information dissemination via Web

Wide-area monitoring system for the ISPs Incident handling

system

Operators Reports to the gov’t and

general users

Recommendations to the member ISPs

Roles of our analysis center

• Real-time monitoring

– from various kinds of network providers – from various types of information sources – for detecting precursors ASAP

• Real-time (automated) analysis

• In-depth analysis (with the experts)

• Archiving events for future analyses

Required functions (1/2)

• Flow control and synchronization

– of different types of monitored data

– of different time resolutions and frames

• Parallel analysis of multiple algorithms

– for finding out clues of new incident trends

• such as virus or DDoS attack breakouts

• Visualization by multiple methods

Required functions (2/2)

• Large-scale incident database storage

– for archiving massive (tera-to-petabyte) amount of incident-related data

– for fast retrieval by the experts and the in-depth analyzing tools

– for storing non-realtime large statistic data

• Workbench for in-depth analysis

Configuration schematics of

the Incident Analysis System

Large-scale Incident Database Flow Control and Synchronization Offline Monitored Data Online Monitored Data Real-time Analysis Process A Real-time Analysis Process B Monitoring Process

Incident Analysis Experts In-depth Analysis Process X In-depth Analysis Process Y Output for visualization, reporting, and recommendation

Monitoring networks and the probes

• Monitoring methods

– Capturing packets (raw and digested) – Blackhole networks

• responding only to ICMP echo requests

• no actual hosts – only attack packets coming

– TCP first-client-packet monitor

• sending a dummy ACK to a SYN request

• Effective to obtain HTTP methods for attacks

A real-time analysis method

example: change-point detection

• Detecting timing of rapid change of a

time-variant data flow

• Faster than repetitive statistical testings

Data flow

Detection Score

Time

Change Point

- Fast real-time learning

- Adaptive to long-term change - Fast detection

- Low false-alarm rate

- Applicable to DDoS by detecting rapid quantitative change of traffics

A change-point analysis example

Change-point score 12/AUG/2004 5am JST 18/AUG/20041pm JST time

MS Blaster activities detected

Other candidate algorithms for the

real-time traffic analysis

• Rare-ratio analysis

– determining how rare an event is, by using the standard/Gaussian distribution model

• Differential analysis

– comparing event rate difference between short-term and long-short-term time frames

• Those analyses are effective for comparing logs of multiple IDSes of different network traffic characteristics

An example of in-depth analysis:

DDoS attacks on a well-known site

• The virus generates simultaneous HTTP requests on specific days of month

• The attacked site can no longer serve normal HTTP requests

• In-depth analysis performed by our engineers

– Using actual traffics captured at the victim server – With cooperation of Telecom-ISAC and OCN (ISP

of NTT in Japan) twice on August 2004 and August 2005

In-depth DDoS analysis summary

(1/2)

• Preprocessing

– per-minute log of captured data – making digests of per-minute logs

• discarding unrelated payload contents • preserving necessary data for analysis • reducing the amount of data to process

– making access history of hosts

In-depth DDoS analysis summary

(2/2)

• Making per-host attack activity ranking

– based on the history of each host

• using numbers of transmitted bytes, packets, HTTP requests, and session connection time

• Profiling based on HTTP methods

– per-hour summary for each method sent

• Passive operating system estimation

Digested log values and fields of

each DDoS attacking packets

+ TCP

- UNIX time() value - Packet length - Source IP address - Destination IP address - IP header flags - TCP header length - “T” for identifying TCP - Source port number

- Destination port number - Sequence number

- Ack number - TCP flags

- TCP payload length

- HTTP method (if existed)

+ UDP

- UNIX time() value - Source IP address

- Destination IP address - IP header flags

- “U” for identifying UDP - Source port number

- Destination port number - UDP payload length

+ ICMP

- UNIX time() value - Source IP address

- Destination IP address - IP header flags

- “I” for identifying ICMP - Type

- Code

DDoS activity of July 31, 2005

1 10 100 1000 10000 100000 1000000 15: 32: 00 15: 51: 00 16: 10: 00 16: 29: 00 16: 48: 00 17: 07: 00 17: 26: 00 17: 45: 00 18: 04: 00 18: 23: 00 18: 42: 00 19: 01: 00 19: 20: 00 19: 39: 00 19: 58: 00 20: 17: 00 20: 36: 00 20: 55: 00 21: 14: 00 21: 33: 00 21: 52: 00 22: 11: 00 22: 30: 00 22: 49: 00 23: 08: 00 23: 27: 00 23: 46: 00 N u m ber s of pa c k e ts GET / HTTP/1.1 GET / HTTP/1.0 POST / HTTP/1.1 POST / HTTP/1.0 POST /cgi-bin/.. HTTP/1.1 POST /cgi-bin/.. HTTP/1.0 GET HTTP/1.1 climbing up

DDoS activity of August 1, 2005

1 10 100 1000 10000 100000 1000000 0: 00 :0 0 0: 46 :0 0 1: 32 :0 0 2: 18 :0 0 3: 04 :0 0 3: 50 :0 0 4: 36 :0 0 5: 22 :0 0 6: 08 :0 0 6: 54 :0 0 7: 40 :0 0 8: 26 :0 0 9: 12 :0 0 9: 58 :0 0 10: 44 :0 0 11: 30 :0 0 12: 16 :0 0 13: 02 :0 0 13: 48 :0 0 14: 34 :0 0 15: 20 :0 0 16: 06 :0 0 16: 52 :0 0 17: 38 :0 0 18: 24 :0 0 19: 10 :0 0 19: 56 :0 0 20: 42 :0 0 21: 28 :0 0 22: 14 :0 0 23: 00 :0 0 23: 46 :0 0 Time in JST N um ber s of pac ke ts GET / HTTP/1.1 GET / HTTP/1.0 POST / HTTP/1.1 POST / HTTP/1.0 POST /cgi-bin/.. HTTP/1.1 POST /cgi-bin/.. HTTP/1.0

GET / HTTP/1.1 traffic jumped up

POST /cgi-bin/... HTTP/1.1 traffic slightly decreased

DDoS activity of August 2, 2005

1 10 100 1000 10000 100000 1000000 0: 00 :0 0 0: 44 :0 0 1: 28 :0 0 2: 12 :0 0 2: 56 :0 0 3: 40 :0 0 4: 24 :0 0 5: 08 :0 0 5: 52 :0 0 6: 36 :0 0 7: 20 :0 0 8: 04 :0 0 8: 48 :0 0 9: 32 :0 0 10: 16 :0 0 11: 00 :0 0 11: 44 :0 0 12: 28 :0 0 13: 12 :0 0 13: 56 :0 0 14: 40 :0 0 15: 24 :0 0 16: 08 :0 0 16: 52 :0 0 17: 36 :0 0 18: 20 :0 0 19: 04 :0 0 19: 48 :0 0 20: 32 :0 0 21: 16 :0 0 22: 00 :0 0 22: 44 :0 0 23: 28 :0 0 N um ber o f pa ck et s GET / HTTP/ 1.1 GET / HTTP/ 1.0 POST / HTTP/ 1.1 POST / HTTP/ 1.0 POST / cgi-bin/ .. HTTP/ 1.1 POST / cgi-bin/ .. HTTP/ 1.0 GET / HTTP/1.1 back to previous amount of traffic

GET / HTTP/1.0 reduced to almost zero after 7am POST /cgi-bin/... HTTP/1.1

Operating systems estimated for

the DDoS attacking hosts

Windows XP (RFC1323, w+) [GENERIC] Windows 2000 SP4, XP SP1 (firewall!)

Windows XP/2000 (RFC1323 no tstamp) [GENERIC]

OpenBSD 3.0 {note: this is probably a Web proxy server OS}

Windows 3.11 (Tucows) (firewall!) Windows XP/2000 [GENERIC]

Windows XP Pro SP1, 2000 SP3 (NAT!) Windows XP Pro SP1, 2000 SP3

Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Windows 2000 SP4, XP SP1

Trends observed from the

monitored DDoS activities

• Increased on the day 1 of the month

– two GET activities

• Steady traffics

– two POST HTTP/1.1 activities – two POST HTTP/1.0 activities

• While the above three trend groups

were the same as in 2004, detailed

Another candidate algorithms for in-depth analysis and visualization: self-organizing maps

similarity detected on incoming TCP packets and HTTP POST methods

similar patterns for / and /cgi... POST methods - SOMs are effective to detect similarities between diffrent datasets

Schedule and things to do

• Research towards data integration needed

– More expertise and research works needed to understand the relationship between data trends and actual incidents happening on the networks – More information sources needed

• We need to be careful on the legal requirements and rights of the network users (i.e., privacy of traffics)

• Schedule

– December 2005: 1st beta-version demo of Incident Analysis Center System