Project Number - diadem firewall

Testbed Specification – DIADEM Firewall Deliverable D12 Project Number : IST-2002-002154 Project Title : Distributed Adaptive Security by Programmable Firewall

DIADEM Firewall

D12 – Testbed Specification Deliverable Type : Dissemination:

Document Public

Contractual date : January 2006 Editor : Piotr Piotrowski (TP) File Name Contributors : See list of authors Version : Final Version Date : January 2006 Deliverable Status: final

Page 1 Copyright © 2004-2006 DIADEM Firewall Consortium

January 2006

Testbed Specification – DIADEM Firewall Deliverable D12

The DIADEM Firewall consists of: Partner

Short name FT

France

2 University of Tübingen IBM Research GmbH Zurich Research 3 Laboratory 4 Imperial College London

TU

Germany

ICL

United Kingdom

5 Jozef Stefan Institute

JSI

Slovenia

6 Groupe des Ecoles des Télécommunications

GET

France

7 Polish Telecom

TP

Poland

1 France Telecom

Country

IBM ZRL Switzerland

Project Management: Yannick Carlinet (FT) Phone +33 2.96.05.03.25 Fax: +33 2 96 05 37 84 E-mail [email protected] France Telecom DAC/R2I 2 ave. Pierre Marzin, 22307 Lannion, France

List of authors: Piotr Piotrowski, TP Ali Fessi, TU Yannick Carlinet, FT Olivier Paul, GET Vrizlinn Thing, ICL Paweł Tobiś, TP

Executive summary This document contains the specifications of the various testbeds that will be used to evaluate implementation. It covers both an overlay network as a general purpose testbed platform and specific configurations which will be used to test selected uses-cases and DIADEM components. It also describes the test traffic models for selected use-cases and test scenarios with examples of performance and functional tests and procedure.


January 2006


Acronyms ANT API AS DMZ FE HTTP IDMEF IP IPFIX ME SM TCP URI VD VPN

Agilent Network Tester Application Programming Interface Autonomous System Demilitarized Zone Firewall Element Hypertext Transfer Protocol Intrusion Detection Exchange Format Internet Protocol IP Flow Information Export Monitoring Element System Manager Transmission Control Protocol URL Resource Identifier Violation Detection Virtual Private Network


January 2006


Table of Contents Executive summary ................................................................................................................................. 2 Acronyms ................................................................................................................................................ 3 Table of Contents .................................................................................................................................... 4 1. Introduction .................................................................................................................................... 5 2. Testbed architecture........................................................................................................................ 5 2.1. An Overlay Network as a Testbed Platform................................................................................... 5 2.2. Specification of France Telecom Testbed ...................................................................................... 6 2.3. Specification of Polish Telecom testbed......................................................................................... 7 2.3.1. General testbed models............................................................................................................... 7 2.3.2. Testbeds based on the Agilent Network Tester .......................................................................... 8 2.4. Specification of GET testbed.......................................................................................................... 9 2.5. Traceback testbed ......................................................................................................................... 10 2.6. TCP SYN flood testbed ................................................................................................................ 11 2.7. HTTP Webserver overloading testbed.......................................................................................... 11 3. Test traffic models ........................................................................................................................ 12 3.1. Test traffic model for TCP SYN flood ......................................................................................... 12 3.2. Test traffic model for WebServer Overloading ............................................................................ 13 4. Test scenarios ............................................................................................................................... 14 4.1. Performance Tests ........................................................................................................................ 14 4.2. Functional Tests............................................................................................................................ 14 4.3. Test Procedure Example ............................................................................................................... 14 5. Conclusion .................................................................................................................................... 15 6. References .................................................................................................................................... 16


January 2006


1. Introduction This document presents an initial specification of the testbeds. The VPN based overlay network interconnecting partner sites to form a testbed platform is first described followed by more detailed descriptions of various test scenarios. We also discuss test traffic models for selected use cases and examples of tests.

2. Testbed architecture 2.1.

An Overlay Network as a Testbed Platform

In order to connect several machines from different DIADEM partners to build a common testbed platform, we built a Virtual Private Network (VPN). The VPN enables the communication between different parts of the testbed while isolating the traffic that belongs to the testbed from other daily traffic. Fehler! Verweisquelle konnte nicht gefunden werden. depicts the overall topology of the VPN. Partners can connect to the VPN using a VPN client. For this purpose, we used the open source tool OpenVPN [1]. The OpenVPN server resides at the University of Tübingen and acts as router between the different VPN clients.

ICL 10.2.x.x

VPN C. VPN C.

TP 10.4.x.x

Internet Internet VPN S.

VPN C.

FT 10.3.x.x

VPN C.

GET 10.6.x.x

VPN C.

TU 10.1.x.x

VPN C.

IBM 10.7.x.x

JSI 10.5.x.x

Figure 1: Overall topology of the VPN

As shown in Figure 1, each partner has a reserved address space in order to keep the configuration of the network simpler. OpenVPN makes use of the OpenSSL library for encryption and authentication. The LZO real-time compression library may be used for increasing the bandwidth for the communication between the different sub-networks. IP packets can be tunnelled within UDP, TCP segments or even HTTP messages to overcome firewalls and proxies within the partners’ networks. Note however that UDP is the most efficient solution, since it has the least overhead.


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 Figure 2 shows an example of a configuration of a sub-network at Imperial College connected to the VPN. The machine where the VPN client is setup acts as a gateway for this sub-network and has an internal IP address (in this case on the interface eth0), for instance, 10.2.255.254. The external IP address (on eth1) is one IP address given by the Internet provider of the partner, which is, for example, the IT service of a university. Packets that are designated to this sub-network are sent by the VPN server through the VPN tunnel. The VPN client receives these packets unpacks them and sends them to a virtual interface (a tun device). From there, they are routed as if they would be arriving from a central router as in Figure 3. ICL 10.2.x.x

eth1

eth0

Internet Internet

VPN client

Figure 2: Example of a configuration a sub-network connected to the VPN

ICL: 10.2.x.x

TP: 10.4.x.x tun

eth0

eth0

tun

tun

tun eth0

eth0

TU: 10.1.x.x

FT: 10.3.x.x tun eth0

eth0 eth0

GET: 10.6.x.x

IBM: 10.7.x.x

JSI: 10.5.x.x

Figure 3: Logical topology of the VPN

The VPN can be used to build various testbed scenarios e.g. to demonstrate the traceback functionality (see Section 2.5) as well as for the Web server overload attack use-case (see Section 2.6) 2.2.

Specification of France Telecom Testbed

Figure 4 gives an overview of the testbed setup by the partner France Telecom. The testbed has two routers that are typically used in an operator production network. The Cisco 7200 is used in the core network while the Cisco 3700 is an edge network router. This setup is representative of the kind of equipment that composes a typical AS (Autonomous System), on a smaller scale. This AS is connected to the FT R&D deployment test network. This network is as close to the FT operational network as possible, and it is used for testing pieces of equipment before they are deployed in the operational network. A connection was setup with the Polish Telecom testbed in order to implement an inter-operator peering point.


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 As indicated in the Figure 4, the FT R&D deployment test network is also connected to a gateway in another sub-network called 'lab network' in the figure. This lab network is an experimental network which is used here because it is connected to the Internet. A tunnel is setup between the gateway and the testbed of Tubingen University, which in turn is connected to the other partners' testbeds.

TP

TU VPN server

FT R&D deployment test network

Lab network

1 Gb link 100 Mb link

Gateway

VPN

Legitimate Client (PC) Core router (Cisco 7200)

Edge router (Cisco 3700)

Victim (PC)

Firewall Device (PC)

Attacker (PC)

Figure 4: Overview of FT testbed

2.3. 2.3.1.

Specification of Polish Telecom testbed General testbed models

Firewalls are tested in an architecture which maps a target work environment onto various combinations of firewalls relating to the possible testbeds. During performance tests of the firewalls we will consider the two most popular functional architectures of firewalls, that is: Dual-Homed and Tri-Homed. The Dual-Homed firewall joins two networks as shown in Figure 5. One of the firewall interfaces is connected to unprotected network, e.g. Internet, the second to a protected network, e.g. internal local enterprise network. In this case, all servers accessible outside are associated with internal network.

Figure 5: Dual-Homed architecture [1]


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 Tri-Homed configuration introduces a third segment, named the demilitarized zone as shown in Figure 6. In this case, servers accessible from public network site are connected to DMZ. Tri-Homed functional architecture has a higher security level, because it allows separating servers from hosts in internal network.

Figure 6: Tri-Homed architecture [1]

The Virtual servers and clients can emulate many hosts and users and so test various profiles of generated traffic. One or more clients can establish connections with many servers during realization of given service. 2.3.2.

Testbeds based on the Agilent Network Tester

Figure 7: Testbed in Dual-Homed architecture based on ANT

The Agilent Network Tester (ANT) Traffic Module in Figure 7 can be used to implement the above virtual servers/clients. There are a maximum of 4 ANT Traffic Modules, so it is possible to connect up to 8 interfaces in tested devices. The Management Network Switch is an Ethernet switch which connects the System Controller with ANT Traffic Modules. The System Controller communicates with ANT Traffic Modules to initialize, execute and monitor tests. The System Controller is a laptop with Agilent NetPressure management software installed. Figure 8 shows the setup for a tri-homed testing architecture.


January 2006


Figure 8: Testbed in Tri-Homed architecture based on ANT

When connected devices do not have Ethernet interfaces a suitable media converter must be used. Further details related to ANT module can be found in ICG04. The ANT Traffic Module can be used to generate incoming traffic from both legitimated users and attackers. Figure 9 shows how the VPN network can be used to connect external objects outside the TP network to the TP network.

Figure 9: Connection TP testbed via VPN technology

2.4.

Specification of GET testbed

As described in Figure 10, the GET testbed is relatively simple. It is partitioned in two subnetworks centred on a 1Gb/s switch: - A first network including several computers represents potential clients for the web server. These clients can also be used as part of experiments in order to generate traffic toward partners' sites. - A second test network represents potential servers. - These two subnetworks are interconnected by a FreeBSD router implementing the HTTP aware monitoring software. The test network is interconnected to the distributed DIADEM testbed using a VPN gateway as described in section Fehler! Verweisquelle konnte nicht gefunden werden.. - The management network is used to access and configure test devices from outside the testbed. This management network centered on a 100Mb/s switch is connected to the Internet through the GET/INT network. GET/INT network is connected to a metropolitan network through a 1 Gb/s link.


January 2006


GET/INT Network

VPN Gateway Linux 2.6 P IV 2Ghz

Management Network 100Mb/s Legitimate User, trafgen Attacker, Httperf FreeBSD 5.2 FreeBSD 5.2 P IV 2Ghz P IV 2Ghz

DIADEM Testbed

WSMon, Router FreeBSD 5.2 P Xeon 2.4Ghz Test Network 1Gb/s

Web Server Apache 1.3 FreeBSD 5.2 P Xeon 2.4Ghz

Test Network 1Gb/s

Figure 10: GET testbed.

2.5.

Traceback testbed

Figure 11: Traceback Testbed

For the Traceback testbed (Figure 11), the attackers, the legitimate clients and the web server reside in different sub-networks. The Monitoring Elements will send IPFIX samples of the traffic flows to the Violation Detection System (to the IPFIX Collector Module). The Traceback Learning Engine will be a detection module within the Violation Detection System. During the learning phase, the Learning Engine will receive, process and store the information with regards to the legitimate routes taken by the clients. When an attack has been detected (e.g. by the SYN flood detection module), it will stop the learning process and start the tracing phase. It will process the data collected by comparing with the one in the database, compute the attack graph (i.e. the routes taken by the attackers), and detect the location nearest to the source of the attack. The results are then sent to the System Manager. This is for deciding on the appropriate response action (e.g. creating or modifying rules on the Firewall Elements).


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 2.6.

TCP SYN flood testbed

TP

JSI

Imperial

GET Agilent Nettester

Attacker

Attacker

VPN server

TU

Attacker

Attacker

1 Gb link Attacker

100 Mb link Unknown VPN

Router in deployment test network

Gateway

FT Legitimate Client (PC)

Core router (Cisco 7200)

Edge router (Cisco 3700)

Victim (PC)

Attacker (PC)

Figure 12: Setup for the TCP SYN flood scenario

Figure 12 shows the location of the attackers and the victim in the TCP SYN flood scenario, as well as the topology of the testbed. Each cloud represents the premises of a partner. Some links are indicated as having an unknown bandwidth because they use a tunnel with best effort quality of service (through the Internet). The attack traffic is generated by a number of PCs located at the partners' premises and by an ANT traffic generator located in a lab at TP. On the PCs we will use a TCP SYN flooding program such as juno, stracheldracht, or tfn, readily available from the Internet. They all generate TCP SYN flood packets to a given destination, with a random source port and address. The victim runs a TCP based service (a web server) which will be the target of the attack. There is also a legitimate client that tries to connect to the service by regular means, in this case with a web browser. Monitoring Elements are run at each partner's site, and when the attack is launched, the detection occurs at the Element the closer to the victim, because this is where the attack traffic is the most noticeable. The monitoring data is received and processed by the Violation Detection and passed to the TCP SYN flood detection module. A notification is generated by the Violation Detection and passed to the System Manager. Counter-measures are then deployed on the Firewall Devices, located at the entry points of the TU testbed and at the inter-connection between FT and TP. 2.7.

HTTP Webserver overloading testbed

As shown in Figure 13 the HTTP server overload testbed is made of several components: - The attack traffic is produced by several attack participants who are located on several partners’ sites. - Legitimate traffic is produced by several legitimate users who are located at different partners’ sites. Page 11 Copyright © 2004-2006 DIADEM Firewall Consortium

January 2006


Figure 13: Testbed for HTTP server overload

-

An HTTP aware traffic monitor is located on the path between the HTTP server and traffic producers. The detection system is located at a partner’s site receiving information from the HTTP aware traffic monitor.

-

3. Test traffic models 3.1.

Test traffic model for TCP SYN flood

The example traffic parameters described below are very dependent on different network conditions. The number of SYN packets per second, directed to target server, is the main parameter. For example, based on the SYN Dog [3] algorithm, it can be assumed that a single server can receive up to 500 SYN packets per second and a single user may generate for example 5 SYN packets. RFC3511 [2] considers the situation when the TCP SYN flood attack influences: i) TCP connection establishment rate, ii) Average HTTP transfer rate. so the model of normal traffic should be expanded with other parameters. Ad. i). Set up parameters are: - for transport layer: number of TCP connections (400 per user1), - for application layer: version of HTTP protocol used by client and server (1.1), HTTP object size (≥100b, 1kb, 8kb, 16kb); Ad. ii). Set up parameters are: 1

For example, in personal router WinRoute is 400.


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 -

for transport layer: number of TCP connections (400 per user), method to close TCP connection (three-way handshake, four-way handshake), direction of close TCP connection request, - for application layer: version of HTTP protocol (1.1), number of GET requests per connection (10, 20), HTTP object size (≥100b, 1kb, 8kb, 16kb). Model of attack traffic is built by increasing the number of SYN packets sends per second above values suggested in the model for normal traffic. Other parameters are unchanged. 3.2.

Test traffic model for WebServer Overloading

In order to allow us to measure the precision of our detection technique, we suggest working with synthetically generated attacks against the server. To simulate attacks we must combine legitimate traffic with traffic generated by attackers and check whether our detection technique is able to: - detect attacks, - identify attackers’ requests. The best way to produce legitimate traffic would be to monitor a real web server when the server is not under attack and to use the captured traffic to generate request in our test environment. This is however not possible in our case: - Live traffic capture is not allowed in our institution for privacy reasons, - Using real life traffic capture would require real time synchronization between our test server and the real server which is not possible for technical reasons. 0

0: P: N:

P

N

time

Beginning server logs/beginning training data. End of training data/beginning of test data. End of test data/end of server logs. Figure 14: Test traffic model for HTTP server overload

As a result, in order to generate legitimate traffic, we place ourselves in a past P and simulate real traffic by replaying requests that were received by the server after time P. One part of log records (received between time 0 and P) is used to build the inference and detection models (Training Data) and the rest (received between time P and N) is used to simulate requests that have been received by the server later on. This is not perfect since: - Its relies on the assumption that the traffic received after time N is related to traffic received between O and N in the same way that the traffic received between P and N is related to the traffic received between O and P. - true sender addresses can not be preserved and requests use the client IP address. This impacts the precision of inference engine which uses IP addresses but does not alter the precision of the current detection scheme which does not rely on IP addresses. During the tests, legitimate traffic is mixed with attack traffic. In order to produce attack traffic we investigated several attack tools including popular bots such as phatbot or agobot in order to understand on which parameters an attacker would be able to play when generating attacks. For each test, attack traffic with different characteristics is generated by varying the following parameters: - Crawler/Random/Fixed requests. In the fixed request setup an object is randomly selected from the server log file records. The same object is then used for every request. In the random setup a new object is randomly selected among records from the server log file for every attack request. Finally in the crawler setup, a different object is selected for each request based on the web server structure and objects inter-dependencies. Page 13 Copyright © 2004-2006 DIADEM Firewall Consortium

January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 -

Attack strength. The strength of the attack is the number of attack requests that are generated per minute. Attack length. The duration of the attack in number of requests. Attack dynamic. An attack is characterized by a fixed value for the previously mentioned parameters. Each attack can then be subdivided into a number of attack sessions separated by a pause. This allows us to check the influence of previous attack sessions on current detection ability.

According to our previous tests a volume of 1Mb/s of attack traffic should be sufficient to detect attacks in the case of our test server. This traffic can be split as shown in Figure 14 or according to other patterns if more participants’ sites are available. For the tests specific traffic generation tools have been developed or used: - For legitimate traffic generation, a tool called trafgen has been developed. It generates requests following the patterns (timing, requested URIs) found in an HTTP server log file. - For attack traffic generation, we suggest using httperf [5] as part of scripts as it allows HTTP traffic generation while allowing fine grain traffic volume control.

4. Test scenarios 4.1.

Performance Tests

During performance testing of firewalls, the following measurements are collected [2] : - Maximum throughput in IP layer – measurement of maximum throughput of firewall and packets forwarding rate in network layer, - Handling of fragmented IP traffic – measurement of impact of fragmented IP traffic on firewall performance, - Maximum number of concurrent TCP connections accepted simultaneously by a firewall, - Maximum TCP connection establish rate, which is related to the maximum rate of refresh of its own connections table by the firewall, - Average HTTP transfer rate – of objects downloaded from HTTP server and forwarding by firewall, - Maximum HTTP transaction rate handled by firewall. It is related to the maximum rate of users’ access to server objects, - Handling of denial of service attack – measurement of denial of service attack impact on TCP connections establishment or\and HTTP transfer rate when under TCP SYN flood attack, - Handling of illegal traffic – measurement of illegal traffic impact on firewall performance. Illegal traffic is dropped by filtering rules, - Volume of latency – measurement of latency of network and application layers which is introduced by firewall. 4.2.

Functional Tests

Many functional tests can be suggested and performed for firewalls. These kinds of tests can be gathered in the following groups, which contain: documentation, installation process, administration & management, security policy, stability & availability of firewall. However, the functional tests for selected use-cases are more useful for DIADEM project. Functional tests for TCP SYN flood may refer to: detect attack using TCP SYN flood Detection Module in VD, system for filtering out of spoofed connections attempts, detect source of attack using traceback. Similarly the examples for the Web Server Overloading may cover the following areas: time and data size impact on accuracy of interference model, detection of attack in dependence of various number of attack requests per minute, limitation of non-established connections. 4.3.

Test Procedure Example


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 We have chosen the handling of denial of service attack as a firewall performance test example. In order to perform the test, we have to set the following parameters on the test tool: a. during test of impact of denial of service on TCP connection establishment rate, the same parameters as in maximum TCP connection establishment rate test should be used, that is: - for transport layer: number of TCP connections, aging time after receive FIN or RST flags, - for application layers: version of HTTP protocol used by clients and servers, HTTP object size; b. during test of impact of denial of service on average HTTP transfer rate, the same parameters as in average HTTP transfer rate test, should be used that is: - for transport layer or lower: Goodput, number of transferred bytes in data field, number of retransmitted bytes, number of timeouts. - for application layer: average HTTP transfer rate, object size, number of correctly transferred objects, test duration. c. Additionally, the SYN attack rate must be set in both cases. Procedure of performing the test may be as follows: a. during test of impact of denial of service on TCP connection establishment rate: 1. Turn off the protection mechanisms against TCP SYN attack, which is available in the tested firewall. 2. Start TCP connections establishment by clients with server or NAT proxy address, with various rate and generation of TCP SYN packets to target server or NAT proxy. 3. Verify correctness of establishment TCP connections and get resultant TCP connection establishment rate by sending GET requests of HTTP protocol by clients related to object downloading. 4. Repeat steps 2.) and 3.) after aging time and when protection mechanisms against TCP SYN flood attack are turn on. 5. Write final values of required result parameters after finishing all iterations. b. during test of impact of denial of service on average HTTP transfer rate: 1. Turn off the protection mechanisms against TCP SYN attack, which are available in the tested firewall. 2. Start generation of GET request by clients with server with various rates. 3. If client generates many GET request per connection, use the same object size for each GET request. 4. Repeat steps 2.) and 3.) with different objects sizes. 5. Write final values of required result parameters after finish all iterations. The test report has to contain values of the same kinds of parameters, as in the test of maximum TCP connections establishment rate (object size, number of correct requests and responses, version of HTTP protocol, number of TCP connections, aging time, time of TCP connections establishment) or average HTTP transfer rate (number of GET requests per connection, object size, average HTTP transfer rate, number/percent of incorrect GET request and responses, version of HTTP protocol, number of TCP connections, method and direction of close TCP connection, number and percent of incorrect established or closed connections) and additionally: SYN attack rate, number of TCP SYN packets, number of TCP SYN packets forwarded by test object. 5. Conclusion This deliverable describes the initial testbeds to be used in the project. The next stage in the test area will be evaluation of Firewall Elements, Violation Detection Facility, and System Manager. The last deliverable will contain detailed test reports.


January 2006

Testbed Specification – DIADEM Firewall Deliverable D12 6. References [1] [2] [3] [4] [5]

“OpenVPN”, http://www.openvpn.net/ Hickman B, “Benchmarking Methodology for Firewall Performance, RFC 3511, April 2003. Wang H., Zhang D., Shin K.: Sniffing SYN Flooding Sources. 2002. Initial Response Management Prototype, DIADEM Firewall deliverable D10, July 2005. D. Mosberger and T. Jin. httperf: A Tool for Measuring Web Server Performance. Performance Evaluation Review, Volume 26, Number 3, December 1998, 31-37.


January 2006