Improving Host Profiling with Bidirectional Flows - IS MU

2009 International Conference on Computational Science and Engineering

Improving Host Profiling with Bidirectional Flows Pavel Minaˇr´ık, Jan Vykopal

Vojtˇech Krm´ıcˇ ek

Institute of Computer Science, Masaryk University Botanick´a 68a, 602 00 Brno, Czech Republic E-mail: [email protected], [email protected]

Faculty of Informatics, Masaryk University Botanick´a 68a, 602 00 Brno, Czech Republic E-mail: [email protected]

Abstract—We present an approach to network devices behavior profiling based on NetFlow monitoring and a bidirectional flows extension. Behavior profiles of network devices typically focus on communicating peers, amount of traffic and traffic structure. However, using an implementation of the bidirectional flows standard we are able to distinguish between servers, clients and single flows directly which increases the profile quality. In this paper, we describe and evaluate our bidirectional flows implementation and suggest to use more precise time stamps in flow monitoring. Further, we compare results obtained by standard behavior profiles (unidirectional flows) and extended behavior profiles (bidirectional flows). Various measurements of extended behavior profile from campus network are presented. The influence of a sensor connection to the monitored network (Cisco SPAN port vs. tap) on the data quality is studied as a side effect of bidirectional flows implementation. Index Terms—behavior profiling, network traffic analysis, bidirectional flows

I. I NTRODUCTION Network traffic monitoring based on observing IP flows and the NetFlow format [9] represents a widely used approach in high-speed networks with a large scope of usage. Network security analysis represents one of the important NetFlow applications, besides others like real-time network monitoring, IP-based accounting/billing, capacity and topology planning etc. Several network intrusion systems ([5], [6]) use this approach for detecting network anomalies. Although, these statistical methods are able to detect massive attacks or massive changes in network behavior, precisely targeted attacks or sophisticated behavior changes are beyond the range of these methods. One of the reasons is that NetFlow standard is defined as unidirectional. Therefore, e.g., a TCP relation is observed as two individual flows which are not interconnected directly. However, their interconnection can be computed as specified in the bidirectional flows standard [18]. The use of bidirectional flows (biflows in short) can improve network devices profiling or statistical methods in general. The bidirectional flows implementation allows to distinguish requests and replies directly. This leads to network devices classification into servers and clients. Especially important in nowadays computer networks is the impact of using bidirectional flows instead of unidirectional ones on security-related flow analysis, as studied in [7]. Several other works illustrates the advantage of using both directions of flow traffic for security analysis, e.g. for scan detection in [16] or for intrusion detection in [21].

978-0-7695-3823-5/09 $26.00 © 2009 IEEE DOI 10.1109/CSE.2009.23

Our implementation of bidirectional flows and network devices profiling builds upon a network traffic processing platform called MyNetScope [4] which is being developed by AdvaICT, a. s. in cooperation with Institute of Computer Science of Masaryk University. This paper is organized as follows. First, we discuss the work related to the idea of bidirectional flows. Network traffic analysis and visualization platform called MyNetScope is briefly introduced in Section III. Section IV deals with details of our implementation of the bidirectional flows standard. The network devices profiling and its extended version is described in Section V. A real profile of a network device and performance details are discussed in Section VI. Finally, the paper is concluded in the Section VII. II. R ELATED WORK The idea of bidirectional flows was presented several years ago, but there are only few works focused on this topic. The concept itself which should reflect the forward and reverse packets of a protocol interchange or session was introduced in [8]. Brownlee et al. described a general framework for monitoring network flows and propose an architecture for traffic flow measurement. This standard also suggests a basic measuring algorithm based on bidirectional counters, but does not specify how to distinguish between the forward and the reverse direction. An extension of IPFIX protocol with an efficient method for exporting bidirectional flow information is described in [18] and also in [7]. There is proposed a bidirectional flow export method using a single flow record. Various possibilities for determining the direction of bidirectional flows are examined and the export method is defined as well. There are several tools which implement bidirectional flows mechanism. One of them is a Yet Another Flowmeter (YAF) sensor. Biflow export is done via the export method specified in [18]. There is also a possibility to export biflows using the Record Adjacency method described in Section 3 of [18]. This is useful when exporting to IPFIX Collecting Processes that are not “biflow-aware”. YAF can read packets from a pcap dumpfile or in real time from an interface via libpcap or libdag [2]. System for Internet-Level Knowledge (SiLK) is a collection of command-line tools for querying SiLK Flow data created by the daemon applications that collect flow data. IPFIX flows are obtained from YAF and NetFlow v5 or v9 data from a router.

231

rwmatch tool can be used for pairing of unidirectional flows. It matches (mate) records as queries and responses and mark mated records with an ID that is stored in the next-hop IP field [3]. Audit Record Generation and Utilization System (Argus) is a bidirectional flow modeler of Layer 2 to Layer 5 network traffic. Argus uses its own record format that is flexible and extensible, supporting generic flow identifiers and metrics, as well as application/protocol specific information [1]. Unfortunately, there is no information available how Argus recognizes the forward and the reverse direction of flows. These implementation of bidirectional flows, except YAF which uses IPFIX data files, use their own network data formats and the usage of their outputs for network device profiling would be difficult. Therefore we decided to implement our own bidirectional flow pairing algorithm (see Section IV) that processes NetFlow records. Also we have not found any work which discusses using bidirectional flows in the relation with network devices profiling, therefore we focus on this extension in Section V. III. M Y N ET S COPE P LATFORM MyNetScope is a network traffic analysis and visualization platform focused on traffic statistics in the NetFlow format [9]. MyNetScope provides an interactive insight into network traffic by combining various visualization methods (graphs – dynamic mind maps, tables, forms and statistical charts) in a single workspace and guides the user through visualization showing more or less detailed information upon a request. Figure 1 shows a screenshot of the application GUI. More details about the visualization method used by MyNetScope is available in [12] and [11]. The purpose of MyNetScope is not only the traffic visualization. It is equipped with a behavior pattern detection based on NetFlow data processing and IP address classification. MyNetScope is one of the first systems that implements the bidirectional flows standard [18] as described in Section IV. One of the behavior pattern detection example is the network devices profiling pattern presented in Section V.

IV. B IDIRECTIONAL F LOWS I MPLEMENTATION A flow, in terms of NetFlow standard, is defined as an unidirectional sequence of packets with some common properties that pass through a network device [10]. The flow is commonly identified by the following 5-tuple: source IP, destination IP, protocol, source port, destination port. Particularly, there is no information about payload. The goal of the bidirectional flows standard is to interconnect requests and replies spread through the data file. Requests and replies are unidirectional flows with the following properties: 1) The value of protocol field of each unidirectional flow is identical to its counterpart in the other flow. 2) The value of source IP address, source port, destination IP address, destination port field of each unidirectional flow is identical to its reverse direction counterpart in the other one. Informally, a flow pair is explained in Figure 3 and single flow in Figure 2. Formally, we define the bidirectional flow pair as follows: (F1 : SrcIPF1 (a)∧SrcPF1 (n)∧DstIPF1 (b)∧DstPF1 (m)∧P rtF1 (p)) ∧ (F2 : SrcIPF2 (b)∧SrcPF2 (m)∧DstIPF2 (a)∧DstPF2 (n)∧P rtF2 (p)) ∧ (F1 → F2 ) ⇒ (F1 , F2 ∈ pair) ∧ (F1 ∈ request) ∧ (F2 ∈ reply) • • • • • • • • •

⇒ - implication Fn - Flow n SrcIPF (a) - source IP address a of flow F SrcPF (n) - source port n of flow F DstIPF (b) - destination IP address b of flow F DstPF (m) - destination port m of flow F P rtF (p) - protocol p of flow F Start(Fn ) - time stamp of flow Fn start F1 → F2 - implies 0 < Start(F2 ) − Start(F1 ) ≤ k, where k > 0 is a paring constant defining the maximum amount of time between the start of two flows that may potentially form a bidirectional pair (biflow)

Fig. 2. Example of a single flow. A computer with IP address A (source port 1053) transferred data to a computer with IP address B (destination port 3899). No reply was detected. Corresponding flow data in NetFlow records: Duration Proto 306.463 UDP Fig. 1. MyNetScope workspace: communication peers and detail information of a selected node. IP addresses and host names are partially blurred here due to privacy concerns.

SrcIP:Port DstIP:Port Packets Bytes A:1053 -> B:3899 36 4544

The pairing procedure’s accuracy depends on the accuracy of the generated time stamps. Accurate time stamps are

232

achieved is sufficient to process about 1,000 flows per second (on cost of-the-shelf hardware) which corresponds to common traffic on a 10Gbps line. V. N ETWORK D EVICES B EHAVIOR P ROFILING

Fig. 3. Example of a flow pair (request and reply) according to Bidirectional flows standard. A client with IP address A from source port 1028 using TCP protocol asked a web server with IP address B on destination port 80 for a web page. The web server replied from source port 80 to destination port 1028 and client’s IP address A using TCP protocol. Corresponding flow data in NetFlow records: Duration Proto SrcIP:Port DstIP:Port Packets Bytes 1.001 TCP A:1028 -> B:80 35 3390 1.467 TCP B:80 -> A:1028 62 88189

essential for the implementation of the bidirectional flows pairing algorithm. For example, the accuracy of the time stamps produced by the software based NetFlow probes is not sufficient in multigigabit networks, since they are obtained via the operating system. Therefore, we suggest to assign the time stamps directly by the hardware card (e.g., hardware-accelerated NetFlow probes FlowMon [19] produced by INVEA-TECH [14]). Low time resolution (only one millisecond) represents another problem in high speed network monitoring. As a result, the request and the reply can have assigned the same time stamp. The ideal resolution would be microseconds otherwise we have to use a heuristic to estimate the request and the reply according to port numbers (a higher source port and a lower destination port is considered to appear in request). The pairing of TCP flows and the client/server/single flow recognition might be further improved by using TCP flags to approximate the flow-initiating packet. The pairing procedure as described is in the O(n2 ) time complexity class. For each flow all other flows have to be examined in worst case. The average complexity depends on a time stamps “density” in NetFlow data. The number of flows fitting the (Start(Fn ), Start(Fn ) + k) interval corresponds to the number of flows which have to be examined when looking for pair of flow Fn . Flows that do not fit the pairing condition presented above are considered to be single flows. These flows might be viewed as requests without replies, e.g., port scans or bias of the primary data caused by Cisco SPAN port connection of the NetFlow probe as presented in [20]. These findings were confirmed by an independent experiment which results are summarized in Table 1. MyNetScope stores and processes NetFlow data in SQL projection. The transformation of unidirectional flows into the bidirectional form is realized by a procedure using standard SQL to access data and order them by time stamp in ascending order. The pairing constant k is initially set to one second and may be changed at any time. Performance is further improved by using database specific optimization features like storing part of the primary data directly in an index. The performance

Changes in network device behavior may indicate device misuse or malfunction. Client workstation that started to run a web server from day to day is certainly suspicious and might be under the control of an intruder. Next, a computer creating much more connections than before might be infected by malware. The recognition of the change in a device behavior on the network level has many advantages in comparison to host based methods (OS independent, highly scalable, misconfiguration tolerant) and was studied in several works such as [15] and [22]. The first step to recognize a change of a device behavior is to build a compact behavior profile and keep track of trends in profile changes. Device profiling has also other usage, e.g. devices with similar behavior may be searched. From the technical point of view a behavior profile is a collection of statistical indicators recorder continuously in time (in suitable time intervals). These statistical indicators should not be influenced by transmission technology or transferred data (packet payload). Transferred data or even application protocols are unavailable in general while the amount of encrypted traffic is growing. Putting these assumptions together leads to usage of NetFlow data and behavior profiles based on number of connections, amount of transferred data, number of packets, services used etc. However, behavior profiles based on NetFlow data are too general. We are able to distinguish between incoming and outgoing traffic but we are not able to identify the initiator of the connection while we have no connections in NetFlow data, only unidirectional data flows. Common behavior profiles available using tools like [13] or [17] contains the following list of indicators: • Communication peers – number of distinct IP addresses which communicate with given IP address. • Amount of traffic – Amount of incoming traffic – amount of traffic in which given IP address is destination IP address. – Amount of outgoing traffic – amount of traffic in which given IP address is source IP address. • Traffic structure – Types of incoming traffic – incoming traffic separated by protocols and ports. – Types of outgoing traffic – outgoing traffic separated by protocols and ports. Such a behavior profile approach is related to many problems. We are not able to distinguish servers and clients easily. For services operating on uncommon ports (greater than 1023) this distinction is almost impossible. There are also problems with port scanning, e.g., a computer permanently scanned on TCP port 80 may look like a broken web server. Such profile may also hide the undesirable network traffic, e.g., tunneling

233

data transfers through port 80 may look like standard web server traffic. We propose an extension of network device behavior profiles based on the bidirectional flows standard. First, the NetFlow data are processed by the pairing algorithm (as described in Section IV) which leads to separation of requests, replies and single flows (request without replies). Flow pairs (requests and corresponding replies) are also connected to each other. Therefore, we are able to distinguish between servers and clients (identify the initiator of the communication) afterward. With this extension we propose a modified behavior profile with the following indicators: • Communication peers – Servers contacted – number of distinct IP addresses where request with reply was sent – Clients answered – number of distinct IP addresses where reply upon request was sent – Single flows – number of distinct IP addresses where request without reply was sent • Amount of traffic – Requests – amount of request traffic (flows, packets, bytes transferred) – Replies – amount of reply traffic (flows, packets, bytes transferred) – Single flows – amount of single flows (flows, packets, bytes transferred) • Traffic structure – Client traffic ∗ Requests – outgoing requests separated by protocols and ports ∗ Replies – incoming replies separated by protocols and ports – Server traffic ∗ Requests – incoming requests separated by protocols and ports ∗ Replies – outgoing replies separated by protocols and ports – Single flows ∗ Scans – outgoing single flows separated by protocols and ports This proposal of the network device behavior profile is resistant to the problems related to standard profiles which do not use biflows. Port scans are disclosed easily and separated into a part of the profile. Devices are also separated into servers and clients and there is no doubt about traffic initiators. From the granularity point of view we consider suitable profile unit as 1 day (24 hours) as it is a typical time unit with expectable behavior. The suitable profile unit also helps to handle holidays or planned outages which have to be treated in a special way, e.g., excluded from the device behavior profile. VI. R ESULTS In this section we summarize experimental results which we have obtained using unidirectional and bidirectional flows in

the campus network. Namely, in Subsection VI-A we present a statistical overview of the single and bidirectional flows distribution in our network. Next, we test various pairing constants and discuss the Cisco SPAN port issues. The following Subsection VI-B shows the performance of our pairing algorithm implementation. In Subsection VI-C, we present a real bidirectional network profile example. Subsection VI-D contains a performance results of the profiling process. Finally, Subsection VI-E focuses on the comparison of the unidirectional and bidirectional behavior profiles in general. A. Bidirectional Flows and Single Flows Statistics In Table I we present number of requests, replies and single flows in the university network. The results are influenced by the pairing constant (results for constants 0.5 s, 1 s and 2 s are presented) and highly depend on the primary data quality. Our results show that the connection of NetFlow probe via SPAN port of an active network device dramatically decreases the data quality compared to the connection via tap (splitter). Connection SPAN SPAN SPAN tap tap tap

Constant (s) 0.5 1 2 0.5 1 2

Flows 75,818 75,818 75,818 84,265 84,265 84,265

Pair flows Count % 57,986 76.48 58,358 76.97 58,688 77.40 78,618 93.30 78,618 93.30 78,620 93.30

Single Count 17,832 17,460 17,130 5,647 5,647 5,645

flows % 23.52 23.03 22.60 6.70 6.70 6.70

TABLE I PAIR FLOWS AND SINGLE FLOWS STATISTICS .

A SPAN port connection was tested on the university edge router (Cisco), NetFlow data corresponds to a traffic of one network segment within a 5 minute interval. A tap connection was tested on the line connecting the monitored network segment to the university network, NetFlow data correspond to a traffic of this segment within a 5 minute interval. The difference of flow count is caused by the fact that the SPAN port is able to capture only the traffic between the segment and Internet but the tap captures all incoming and outgoing traffic of this segment. Two conclusions arise from the presented example. Firstly, the pairing constant set to 1 second corresponds to common traffic properties well. An increase or decrease of the pairing constant has minimal influence on the resulting pair flow count. Secondly, it has been validated that SPAN port dramatically reduces the quality of NetFlow data generated by a probe connected to it. This is caused mainly by the duplication of packets that results in flows with nondeterministic number of packets. Unfortunately, the present architecture of our network does not allow us to compare the same traffic monitored using a probe connected to a SPAN port and a probe wired to tap. B. Bidirectional Flows Pairing Algorithm Performance We have validated performance of our bidirectional flows implementation at a middle range quad core single CPU server with 8GB RAM and SAS drives in RAID 1. In Table II

234

Weekday

we present results for the bidirectional flows implementation running on 32bit system and 64bit system. 64bit architecture leads to performance improvements. Flow count 319,968 897,028

32bit time 144 s 1,102 s

32bit rate 2,222 fps 814 fps

64bit time 116 s 853 s

Mon

Tue

64bit rate 2,758 fps 1052 fps

Wed

TABLE II P ERFORMANCE RESULTS OF BIDIRECTIONAL FLOWS IMPLEMENTATION .

Thu

Fri

It is clear that performance at approximately 1,000 flows per second (fps) is not enough and has to be improved. In our university network average traffic is about 2,500 flows per second while peaks grow up to 5,000 flows per second. However, for particular tasks like dictionary attack detection the achieved performance is sufficient as presented in [20].

Role Server Client Server Server Client Server Server Client Server Server Client Client Server Server Client

Proto TCP UDP UDP TCP UDP UDP TCP UDP UDP TCP TCP UDP TCP UDP UDP

Port 80 53 53 80 53 53 80 53 53 80 3194 53 80 53 53

Req c. 26k 799k 626k 21k 789k 564k 13k 419k 284k 22k 40 777k 20k 1,141k 687k

Req a. 38MB 62MB 52MB 32MB 91MB 51MB 20MB 32MB 23MB 31MB 158MB 60MB 32MB 74MB 53MB

TABLE IV S ERVER TRAFFIC STRUCTURE IN ONE WORKWEEK – TOP 3 SERVICES ORDERED BY AMOUNT OF TRANSFERRED DATA .

C. Example of a Real Network Device Behavior Profile As an example of real network device behavior profiles based on bidirectional flows, we present a business week profile of one of our university servers in a Table III. The profile is computed using NetFlow data collected at the university edge router therefore inner university traffic of this server is out of range. The most important difference between our profile and the common approach is the direct distinction of client, server and single traffic contrary to incoming and outgoing traffic as usual. Please note that the profile is negatively influenced by the probe connection using a SPAN port as was presented in the Subsection VI-A. Component Req c. Req a. Req t. Rep c. Rep a. Rep t. Singles c. Singles a. Singles t.

Mon 951k 702MB 53,830 704k 1,688MB 74,576 180k 1,256MB 21,318

Tue 926k 1,004MB 51,344 621k 1,476MB 69,347 305k 780MB 34,758

Wed 499k 413MB 36,138 318k 616MB 46,807 87k 409MB 11,929

Thu 938k 843MB 54,566 708k 1,588MB 73,604 162k 478MB 19,669

Rep c. 26k 799k 626k 21k 789k 564k 13k 419k 284k 22k 40 777k 20k 1,141k 687k

Fri 943k 736MB 49,913 1,206k 1,830MB 66,728 180k 924MB 16,916

Fig. 4.

Relative biflows count for top 3 services

TABLE III S ERVER BEHAVIOR PROFILE IN ONE BUSINESS WEEK – FLOW COUNT, AMOUNT OF TRANSFERRED DATA , COMMUNICATION PEERS COUNT, c. STANDS FOR COUNT, a. STANDS FOR AMOUNT, t. STANDS FOR TARGETS .

Table IV and Figures 4 and 5 summarize top 3 services in particular days during a workweek. The table needs more comments to understand it well. First, we have to distinguish between server roles and client roles. Requests within server role are incoming traffic generated by the client machines, replies are outgoing traffic generated by the profiled device. Request within client role are outgoing traffic generated by the profiled device and replies are incoming traffic generated by servers replying to given requests.

Fig. 5.

235

Relative biflows volume for top 3 services

Rep a. 625MB 145MB 120MB 689MB 161MB 146MB 352MB 75MB 52MB 463MB 2.2MB 140MB 572MB 410MB 123MB

In the presented traffic structure profile we can notice two anomalies: • Communication to port 3194 using TCP protocol on Thursday – the profiled device initiated communication and transferred about 160MB. This communication is within the profile unique and therefore suspicious. We further investigated this event and found out that it was a FTP data transfer in FTP passive mode (the initial handshake was observed on TCP port 21). • Double increase of DNS traffic on Friday – in comparison to other days the profiled device answered two times more DNS requests then in other days. Further analysis reveals a massive distributed attack on DNS server. Unfortunately, the analysis was complicated by inaccurate timestamps assigned to packets passing through the SPAN port.

Flow count 57,000 204,500

Pairing 9s 56 s

Peers 2s 3s

Amount 1s 3s

Structure 39 s 49 s

TABLE V P ERFORMANCE RESULTS OF BEHAVIOR PROFILES IMPLEMENTATION , 57,000 FLOWS CONCERN 3 PROFILED IP ADDRESSES , 204,500 FLOWS CONCERN 4 PROFILED IP ADDRESSES .

E. Unidirectional and Bidirectional Profile Comparison In this last subsection we focus on comparison of two behavior profiles computed using the same primary data. The first profile (Table VI) uses a common NetFlow data without bidirectional flows extension and therefore is able to distinguish only incoming and outgoing traffic. The second profile (Table VII) derives benefits from NetFlow enhanced by bidirectional flows. Therefore distinction between server and client traffic is possible. As the concrete example will serve DNS traffic of a university server presented in Table IV. The relation between in/out traffic and flow pair kind (request/reply) is explained in Table VIII. The contribution of bidirectional flows in network device profiling is obvious. We are able to separate incoming and outgoing traffic more deeply into server behavior and client behavior of a network device. Server and client distinction is of advantage when exploring unknown networks. While the common approach enables to identify top n talkers or top

Outgoing traffic Transferred Flow count 463 MB 1,828 k

TABLE VI DNS BEHAVIOR PROFILE BASED ON UNIDIRECTIONAL N ET F LOW DATA .

Service DNS server DNS client

Incoming traffic Transferred Flow count 74 MB 1,141 k 123 MB 687 k

Outgoing traffic Transferred Flow count 410 MB 1,141 k 53 MB 687 k

TABLE VII DNS BEHAVIOR PROFILE BASED ON BIDIRECTIONAL N ET F LOW DATA .

Role Client (IP A) Server (IP B)

D. Performance of Network Device Profiling Network device behavior profiling was evaluated on the same machine as described in Subsection VI-B in its 64bit implementation. We present brief performance results of device behavior profiling according to the number of flows in Table V. First, NetFlow data have to be preprocessed by the pairing procedure to obtain biflows. Then the behavior profile is computed. This means additional computational time. Processing time for each of the profile part (communication peers, amount of traffic and traffic structure) is presented separately.

Incoming traffic Transferred Flow count 197 MB 1,828 k

Service DNS

Incoming traffic replies (destination IP A) requests (destination IP B)

Outgoing traffic requests (source IP A) replies (source IP B)

TABLE VIII R ELATION BETWEEN INCOMING ( OUTGOING ) TRAFFIC AND REQUEST ( REPLIES ) ACCORDING TO THE DEVICE ROLE .

n services in the network, bidirectional flows make possible to identify the top n servers or top n clients, top n offered services or top n used services. Another example comes from the security domain. Direct communication between clients may be considered as suspicious and should be investigated in more detail. VII. C ONCLUSION AND F UTURE W ORK We have presented one of the first implementations of bidirectional flows used for device behavior profiling. We believe that bidirectional flows have a great potential in network performance engineering (e.g. server response measurement) or network security. Namely, experimental device profiling showed an anomaly that was recognized as a distributed attack against the DNS server. Proposed network devices behavior profiles overcome the limits given by the unidirectionality of NetFlow data. Using bidirectional flows we are able to separate servers, clients and port scans naturally and project these components of traffic into the profiles. In our future work we will focus on performance improvements. We plan to implement bidirectional flows directly into NfSen [13] NetFlow collector. Behavior profiles itself has to be optimized. The size of the traffic structure part of the profile might grow up rapidly. One of the reasons is that the NetFlow probe is connected via SPAN port which leads to packet duplications and profile disturbance. Profiles are designed as lossless. However, this is untenable in real usage and the traffic structure profile has to be aggregated or an insignificant part of the profile has to be discarded. The behavior profiles as presented have a great potential in anomaly detection systems. One of the interesting usage of behavior profiles is the similarity search applied on network

236

devices according to their profiles. All we need is to find suitable metrics. ACKNOWLEDGMENT This work in domain of network devices behavior profiling using bidirectional flows was supported by the Czech Ministry of Defence under Contract No. SMO02008PR980-OVMASUN200801.

R EFERENCES [1] Argus homepage. http://qosient.com/argus/, 2009. [2] Manual page of yet another flowmeter. http://tools.netsa.cert.org/yaf/yaf.1.pdf, 2009. [3] Silk documentation. http://tools.netsa.cert.org/silk/silk docs.html, 2009. [4] AdvaICT, a.s. MyNetScope Platform - Product Page. http://www.advaict.com/mynetscope. [5] Agent Technology Group, Gerstner Laboratory, Czech Technical University in Prague and Institute of Computer Science, Masaryk University in Brno. CAMNEP (Cooperative Adaptive Mechanism for NEtwork Protection) project web page. http://http://agents.felk.cvut.cz/projects/camnep. [6] Tarem Ahmed, Mark Coates, and Anukool Lakhina. Multivariate online anomaly detection using kernel recursive least squares. In INFOCOM, pages 625–633, 2007. [7] Elisa Boschi and Brian Trammell. Bidirectional Flow Measurement, IPFIX, and Security Analysis. FloCon 2006, 2006. [8] N. Brownlee, C. Mills, and G. Ruth. Traffic Flow Measurement: Architecture. RFC 2722 (Informational), October 1999. [9] Cisco Systems. Cisco IOS NetFlow. http://www.cisco.com/go/netflow, 2007. [10] B. Claise. Cisco Systems NetFlow Services Export Version 9. RFC 3954 (Informational), October 2004. [11] Tom´asˇ Dym´acˇ ek, Petra Hocov´a, and Miroslav Kintr. Adaptable visualization service: through uniformity towards sustainability. In Model Driven Interoperability for Sustainable Information Systems (MDISIS’08), Montpellier, France, 2008. [12] Tom´asˇ Dym´acˇ ek and Pavel Minaˇr´ık. Netflow data visualization based on graphs. In Visualization for Computer Security, 5th International Workshop, VizSEC 2008 Proceedings, pages 144–151, 2008. [13] Peter Haag. NfSen - NetFlow Sensor. http://nfsen.sourceforge.net, 2007. [14] INVEA-TECH Inc. INVEA-TECH Inc. Company Profile. http://www.invea.cz/main/home. [15] Thomas Karagiannis, Konstantina Papagiannaki, Nina Taft, and Michalis Faloutsos. Profiling the end host. In PAM 2007, pages 186–196, 2007. [16] Ramana Rao Kompella, Sumeet Singh, and George Varghese. On scalable attack detection in the network. In IMC ’04: Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, pages 187–200, New York, NY, USA, 2004. ACM. [17] Mycroft Mind Inc. NetFlow Visualizer. http://www.mycroftmind.com/products:nfvis. [18] B. Trammell and E. Boschi. Bidirectional Flow Export Using IP Flow Information Export (IPFIX). RFC 5103 (Proposed Standard), January 2008. ˇ [19] Pavel Celeda, Milan Kov´acˇ ik, Tom´asˇ Kon´ıˇr, Vojtˇech ˇ ˇ adn´ık. Krm´ıcˇ ek, Petr Springl, and Martin Z´ FlowMon Probe. Technical Report 31/2006, CESNET, z. s. p. o., 2006. http://www.cesnet.cz/doc/techzpravy/2006/flowmon-probe. [20] Jan Vykopal, Tom´asˇ Plesn´ık, and Pavel Minaˇr´ık. Validation of networkbased dictionary attack detection. In Proceedings of SPI 2009: Security and Protection of Information (to appear), 2009. [21] David Watson, Matthew Smart, G. Robert Malan, and Farnam Jahanian. Protocol scrubbing: Network security through transparent flow modification. DARPA Information Survivability Conference and Exposition, 2:1108, 2001. [22] Songjie Wei, Jelena Mirkovic, and Ezra Kissel. Profiling and clustering internet hosts. In DMIN, pages 269–275. CSREA Press, 2006.

237