**4. Proof of concept**

114 Earthquake Research and Analysis – Statistical Studies, Observations and Planning

The implementation of IFS level 3 happens at the gateway of the LAN. IFS level 3 is analogous to IFS level 2, as it queries databases generated by IFS levels 1 and 2. Likewise IFS level 1, some security devices may be installed at the gateway (as firewall, regular IDPS, etc) and they may also be analyzed. The steps for analysis at this level are: a) Network security devices record UIT in databases; IFS level 3 queries the databases provided by the lower levels and current level; b) IFS level 3 analyzes the provided databases to define trends; c) IFS level 3 provides feedback of the trend analysis to the security devices; d) IFS level 3 may also give feedback for the lower levels. It is important to notice that IFS level 1 and level 2 databases work as sensors

IFS level 4 is the major level. It considers the structure of the backbone providers (an ISP, for instance). In the same way IFS level 3 and level 2, different security devices are linked to the backbone level. The steps for IFS level 4 to work are: a) Backbone security devices record UIT in database; b) IFS level 4 queries the databases provided by the lower and current level; c) IFS level 4 analyzes the provided databases to define the trends; d) IFS level 4 provides feedback of the trend analysis to the current level; e) IFS level 4 may also give feedback for the lower levels. Similarly to lower levels, IFS level 4 uses the same concept of sensors: lower databases and the entire lower IFS levels are sensors for IFS level 4. An important note is: the IFS level 4 may be shared and correlated among various backbone providers. To correlate forecasts of IFS level 4 means to provide the most realistic and integrated trend about UIT, as it may spread sensors along the network (Lajara et al, 2007). It is important to notice that for the IFS we implemented a two stage system (Pontes et al, 2011), intending to improve the forecasting results by the use of correlation. Fig. 7 presents

1. The first task is the multi-correlation, running the EAS, to filter FP and tracing sophisticated. During this step, OS's logs, IDPS's logs, network traffic and other logs are analyzed by the EAS. According to Fig. 4, diverse logs and network traffic represent the

Fig. 6. DIFS Architecture - adapted from (Pontes & Guelfi, 2009)

for IFS level 3. The sensor elements may be more numerous at IFS level 3.

the sequence of activities done by the system:

Entry 1 for the two stage system.

In this section we are going to describe two of the prototypes we have prepared and analysed. In the first one (Pontes et al, 2009), for the proof of concept, levels 1, 2 and 3 of the DIFS were implemented in three sites geographically divided (A, A' and A''). The following hardware and services were used: a) 1 Pentium core 2 quad 2.0 GHz, 8GB RAM; b) 2 Pentium core 2 duo 1.8 GHz, 4GB RAM; c) 10 virtual machines (Ubuntu 8.04) 512MB RAM; d) 4 virtual machines (WindowsXP) 512MB RAM; e) Windows Vista (host for the virtual machines); VMware Player 2.51; Snort; Netfilter/Iptables; MySQL; OpenVPN.

Likewise (Haslum et al, 2008), in this prototype the simulation of UIT was divided in just in four types: 1) Denial of service (DoS): Ping of Death and SYN Flood are examples of this kind of UIT; 2) Remote to local (R2L): SQL injection is an example of this kind of UIT, where typical vulnerabilities that are exploited is buffer overow and pure environment sanitation; 3) User to root (U2R): SQL injection is also example of this kind of UIT; 4) Probe (Scanning): Nmap, IPswep, Satan are examples of software for scanning. During eight weeks, we simulate usual network traffic and UIT among hosts in each site. Normal network traffic and UIT were also simulated among sites. H-IDPS (NIST SP800-94, 2007) was installed in each one of the hosts. N-IDPS (NIST SP800-94, 2007) was installed at the gateway. Fig. 8 illustrates the sites, hosts with normal activities and infected hosts. Infected hosts inflict UIT to the hosts of each site and to hosts from other sites, as pointed by arrows. In this prototype, the propagation of UIT was in the following sequence: from site A to site A', from site A and A' to site A", from site A, A' and A" to site A. For this prototype, IFS was developed in JAVA and it runs in the three levels of DIFS. The IDPS Snort was used to analyze the network traffic. All classified UIT is lately recorded in a MySQL database. IFS collects data from the database, analyzes them and next, when a particular threshold of UIT is exceeded, a warning is sent to the IFS collaborators.

For the second prototype (Pontes et al, 2009), the two stage system was implemented and employed in a wired LAN, specifically in a computer working as gateway for the Internet (level 3 of the DIFS). Elements of level 1 (logs from the OS) were used in the. Although level 3 of the DIFS was approached, level 1, 2 and 4 were disregarded in the second prototype. The reason for implementing only level 3 is the representativeness of the gateway level: (a) the simulated cyber-attacks and the real network traffic have just one path to reach the Internet: throughout

Earthquake Prediction: Analogy with Forecasting

Table 2. Services in the Prototype (Pontes et Al, 2011)

EAS Visual FoxPro

Table 3. Experiment Applications (Pontes et Al, 2011)

Graphs Graphviz

XP Prof. (Ultr@VNC Server 1.0).

the OS' logs.

Models for Cyber Attacks in Internet and Computer Systems 117

The computer working as gateway (DIFS level 3) was able to register all alerts of the Network IDPS and logs from its own OS. Table 2 details services used in the two stage system, as the source machines for each service and the reached destiny for each service. In the environment for the tests, multi-correlation was done between alerts from an IDPS with

Table 3 presents applications which were used in the prototype. EAS was developed by the authors, in Visual FoxPro. Finally, Table 3 shows the elapsed time for the prototype. Both simulation of normal network traffic and simulation of cyber-attacks were referred in the prototype. Normal network traffic was brought up as well. Unlike (Pontes et al, 2008), (Pontes & Guelfi, 2009a), (Pontes & Guelfi, 2009b), (Pontes & Zucchi, 2010) Cyber-attacks concern the following types: (1) AWStats - allows remote attackers to execute arbitrary commands via shell; (2) SNMP: remote attackers can cause a DoS or gain privileges via SNMPv1 trap handling (SNMP AGENTX/TCP REQUEST is an example of this kind of attack); (3) P2P: multiple TCP/IP and ICMP implementations allow remote attackers to

Internet browser 14 and 23 Internet Remote access (VNC) 59 and 106 Gateway Peer-to-peer (Bitcomet) 59 Internet E-mail server (Winconnection) 59 Internet Complete attack test (Fast-Track) 65 Gateway Complete attack test (Nessus) 204 Gateway

cause a DoS (reset TCP connections) via spoofed ICMP error messages.

Features Applications Time (m) Details

IDPS Snort 19 13113 signatures logs Detection Procmon 19 752851 logs

The following hardware were used for our prototype: gateway - Intel Core 2 Duo 2.66 GHz, 3 GB RAM – Windows XP Professional; number 65 – VMWare Workstation 6.0.2 768 MB RAM – Fedora 10 (Fast Track); number 204 - VMWare Workstation 6.0.2 512 MB RAM – Fedora 10 (Nessus Server 4.0.2); number 14 – Intel Core 2 Duo 2.5 GHz, 4 GB RAM – Windows XP Professional (browser's Internet access); number 23 – Intel Pentium 4 3.2 GHz, 4 GB RAM – Microsoft Windows 7 (browser's Internet accesss, Bitcomet 1.17); number 59 – Intel Pentium 4 3.06 GHz, 1 GB RAM – Windows XP Professional (Winconnection E-mail Server 4.6f, Ultr@VNC Viewer 1.0); number 106 – Intel Pentium 4 2,4 GHz, 2 GB –Windows

It is important to notice that the cyber-attacks considered in this prototype are, in matter of fact, a set of events (alerts and logs) classified as a single and more elaborated attack. In our earlier works (Pontes et al, 2008), (Pontes & Guelfi, 2009a), (Pontes & Guelfi, 2009b), (Pontes & Zucchi, 2010), forecasting techniques considered just individual events in the cybersecurity context. Consequently in this paper forecasting techniques are differently

Services Source machine Destiny

the gateway; (b) at the gateway level it was possible to assure timestamp conditions for correlation processes, as the IDPS is set at the same machine, the EAS and the gateway.

Fig. 8. DIFS Prototype – adapted from (Pontes & Guelfi, 2009)

Fig 9 illustrates the LAN for the tests, which is based on the diversity: diverse machines, settings, protocols and services are executed; further more there are several OS and free access to the Internet. Virtualized OSs (Linux Fedora), using VMWare, the host operational systems with Windows 7 and Windows XP are used in the prototype.

Fig. 9. Environment for Tests of the TSS – Computers, OSs and Services (Pontes et al, 2011)

the gateway; (b) at the gateway level it was possible to assure timestamp conditions for

Fig 9 illustrates the LAN for the tests, which is based on the diversity: diverse machines, settings, protocols and services are executed; further more there are several OS and free access to the Internet. Virtualized OSs (Linux Fedora), using VMWare, the host operational

Fig. 9. Environment for Tests of the TSS – Computers, OSs and Services (Pontes et al, 2011)

correlation processes, as the IDPS is set at the same machine, the EAS and the gateway.

Fig. 8. DIFS Prototype – adapted from (Pontes & Guelfi, 2009)

systems with Windows 7 and Windows XP are used in the prototype.

The computer working as gateway (DIFS level 3) was able to register all alerts of the Network IDPS and logs from its own OS. Table 2 details services used in the two stage system, as the source machines for each service and the reached destiny for each service. In the environment for the tests, multi-correlation was done between alerts from an IDPS with the OS' logs.


Table 2. Services in the Prototype (Pontes et Al, 2011)

Table 3 presents applications which were used in the prototype. EAS was developed by the authors, in Visual FoxPro. Finally, Table 3 shows the elapsed time for the prototype. Both simulation of normal network traffic and simulation of cyber-attacks were referred in the prototype. Normal network traffic was brought up as well. Unlike (Pontes et al, 2008), (Pontes & Guelfi, 2009a), (Pontes & Guelfi, 2009b), (Pontes & Zucchi, 2010) Cyber-attacks concern the following types: (1) AWStats - allows remote attackers to execute arbitrary commands via shell; (2) SNMP: remote attackers can cause a DoS or gain privileges via SNMPv1 trap handling (SNMP AGENTX/TCP REQUEST is an example of this kind of attack); (3) P2P: multiple TCP/IP and ICMP implementations allow remote attackers to cause a DoS (reset TCP connections) via spoofed ICMP error messages.


Table 3. Experiment Applications (Pontes et Al, 2011)

The following hardware were used for our prototype: gateway - Intel Core 2 Duo 2.66 GHz, 3 GB RAM – Windows XP Professional; number 65 – VMWare Workstation 6.0.2 768 MB RAM – Fedora 10 (Fast Track); number 204 - VMWare Workstation 6.0.2 512 MB RAM – Fedora 10 (Nessus Server 4.0.2); number 14 – Intel Core 2 Duo 2.5 GHz, 4 GB RAM – Windows XP Professional (browser's Internet access); number 23 – Intel Pentium 4 3.2 GHz, 4 GB RAM – Microsoft Windows 7 (browser's Internet accesss, Bitcomet 1.17); number 59 – Intel Pentium 4 3.06 GHz, 1 GB RAM – Windows XP Professional (Winconnection E-mail Server 4.6f, Ultr@VNC Viewer 1.0); number 106 – Intel Pentium 4 2,4 GHz, 2 GB –Windows XP Prof. (Ultr@VNC Server 1.0).

It is important to notice that the cyber-attacks considered in this prototype are, in matter of fact, a set of events (alerts and logs) classified as a single and more elaborated attack. In our earlier works (Pontes et al, 2008), (Pontes & Guelfi, 2009a), (Pontes & Guelfi, 2009b), (Pontes & Zucchi, 2010), forecasting techniques considered just individual events in the cybersecurity context. Consequently in this paper forecasting techniques are differently

Earthquake Prediction: Analogy with Forecasting

Table 6. Prototype Results (Pontes et al, 2009)

comparisons: the DIFS level 3 work\ing without EAS.

Fig. 10. P2P Graph Attack (TP + FP alerts) (Pontes et al, 2009)

Fig. 11. True Positives + False Positves for P2P Attack (Pontes et al, 2009)

Models for Cyber Attacks in Internet and Computer Systems 119

Fig. 10 depicts the amount of FP which was detected, considering a preliminary correlation without FP filters. Notice there are 17 alerts (nodes) with 69 correlations among them (connections between alerts represented by arrows). Fig. 10 denotes the first scenario for

 Values Total Detected alerts 2554 Gateway 1588 Non-gateway 4142 Alert types 137 Isolated alerts 29 (all in FP1) 21 FP / 8 TP 72,41% FP

% FP 21.08 (FP1) 44.72% (FP3) 54.22% % TP 45.78% 10.52% of all TP alerts were isolated

Correlated alerts 14 FP1 = 21.08% 55 FP3 = 44.72%

employed, considering the DIFS architecture, as the prototype deals with more refined sets of attacks. Details regarding the EAS and the IFS tasks are not reported in this chapter due space limitations, but the reader may consult (Silva & Guelfi, 2010), (Silva, 2010) and (Pontes et al, 2008), (Pontes & Guelfi, 2009a), (Pontes & Guelfi, 2009b), (Pontes & Zucchi, 2010) for more information relating to EAS and IFS, respectively.
