SVILUPPO DI UNA TECNICA DI RICONOSCIMENTO STATISTICO DI APPLICAZIONI SU RETE IP

Transcription

1 UNIVERSITÀ DEGLI STUDI DI PARMA FACOLTÀ di INGEGNERIA Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni SVILUPPO DI UNA TECNICA DI RICONOSCIMENTO STATISTICO DI APPLICAZIONI SU RETE IP Relatore: Chiar.mo Prof. LUCA VELTRI Tesi di Laurea Specialistica di: RICCARDO PECORI Anno Accademico 2006/2007

2 PARTE II 2. Motivations M any network management tasks, such as flow prioritization, traffic policing and diagnostic monitoring, require always oftener accurate identification and categorization of network traffic according to the type of application that has generated it [2][2]. The identification, which can be packet, flow or session-based, is becoming a fundamental prerequisite for numerous other network activities, such as granting an adequate level of QoS (e.g.: differentiated services, priority queuing, minimum bit-rate, ) or managing ISPs billing policies [3][4]; moreover it can help in solving some network engineering problems such as workload characterization and modelling, capacity planning and route provisioning. A reliable traffic characterization could be also a good starting point, for network administrators, either to investigate in case of sudden changes in traffic dynamics and to counter possible security attacks. There are (see [4]) at least three categories of application identification methods: Session-based, Content-based and Constraint-based. 16

3 Figure 1: Application Traffic Identification Methods The traditionally used classification methods, such as well-known port identification or exhaustive packet payload analysis, belong, respectively, to the first and second category; they are becoming obsolete and helpless in front of the emerging of peer-to-peer applications and mechanism such as tunnelling and encryption used mainly to avoid detection or violate security policies. A detailed description of features and drawbacks of these methods follows. 17

4 2.1 Well Known-Port based Methods Known-port methods rely on the observation of TCP or UDP port numbers, which are divided into three ranges: the Well Known Ports (0-1023), the Registered Ports ( ) and the Dynamic and/or Private ports ( ). A typical TCP connection starts with a SYN, SYN-ACK, ACK handshake from client to server; the client addresses its initial SYN packet to the well known server port of a particular application. The source port number of the packet is typically chosen dynamically by the client. UDP uses ports similarly to TCP but in a connectionless way. All successive packets in either a TCP or UDP session will use the same pair of ports to identify the client and the server side of the session; therefore, in principle, the TCP or UDP server port number can be used to recognize the higher layer application, by simply identifying which port is the server port and mapping this port to an application using the IANA (Internet Assigned Numbers Authority) list of registered ports [6]. However these methods are often unusable because of some limitations [1][7]: First, the mapping from ports to applications is not always well defined; many implementations of TCP use client ports in the registered range. Some applications such as P2P applications (e.g.: Kazaa, Napster) haven t standard port numbers and began using dynamic ports and disguising themselves by using port numbers for commonly used protocols such as HTTP and FTP, there are ambi- 18

5 guities in the port registrations, etc.. A second limitation is that a port can be used by a single application to transmit traffic with different QoS requirements; for example Lotus Notes transmits both and database transaction traffic using the same ports, and scp (secure copy), a file transfer protocol, runs over SSH (secure shell) which is also used interactively on the same port (TCP port 22) by remote shell applications. 19

6 2.2 Payload-based Analysis Methods The aforementioned disadvantages of port-based classification led to several payload-based analysis techniques [2], in which there is a research of characteristic prints of known applications. These techniques avoid completely the reliance on fixed port numbers [7]. In the so called Signature Matching Method, a portion of payload data, indicated as the signature of the application, that is static, unique and distinguishable, is examined for all applications, regardless of their protocol. This method tries to identify the application by comparing every packet payload with pre-determined signatures. Many Network Intrusion Detection Systems (NIDS) rely on signature-based techniques to recognize known attack patterns on standard service ports. The choice of these methods is due to their quickness and their efficiency in recognizing known attacks without generating too many false alarms ([10], [11]). The Protocol Matching Method shares a similar concept of signature matching but it needs to be aware of the complete protocol format. Ethereal [9], which will be exploited in the practical realization of the thesis, is a monitoring tool that offers the protocol matching functionality. Besides some benefits, these payload based mechanisms, on the other hand, require in advance an exhaustive search frequent updates of signature information to maintain the high accuracy; these are operations that impose significant complexity and processing load on the traffic identification device [7]. 20

7 Moreover they become useless in front of tunnelling and encryption mechanisms. Let s see how Tunnelling Techniques The application level payload of at least two protocols (HTTP and DNS) could in principle be used to encapsulate packets generated by other protocols and to carry them hidden in and out of a given network. Exploiting these features and the fact that network administrators normally let HTTP and DNS traffic pass their network boundaries, one can install entry and exit points in different places of Internet and therefore bypass any security policy enforced by firewalls or proxy [12]. A popular, open source package capable of tunnelling any application level protocol into HTTP is [13]. It provides two daemons, htc and hts, running at the two ends of the tunnel; htc listens for incoming TCP connections at a given port, when a connection is established htc opens a couple of HTTP sessions towards hts that runs at the opposite side of the tunnel. For example, if SMTP (port number 25) is tunnelled into HTTP (port number 80), hts will forward any incoming connection on port 80 to port 25, while htc will redirect any request to port 80 of the server. The packet of the tunnelled flows are encoded so that they can be incorporated in a regular, semantically valid HTTP session; an analysis of the TCP payloads, even if performed by means of pattern matching, could not reveal any difference between the htc/hts traffic and a true HTTP flow. 21

8 2.2.2 Encrypted Traffic Examples A practical example of the uselessness of signature-based methods when cryptography is employed is Skype traffic [14]. Skype is a very popular VoIP software whose protocols and algorithms are unknown and follow a closed source and proprietary design that leverages on strong encryption mechanism; so it is very difficult to even identify the presence of Skype traffic in a traffic aggregate. Only few pieces of information about Skype messages building are available: a Codec encodes the voice, a Framer multiplexes into a single Skype frame some encoded blocks, a Cypher encrypts a frame once it has been created, and finally an additionally not ciphered header (Start of Message) may be added. The result is a Skype message. Only if it is present the SoM a payload-based classifier can be used. In fact, although a PBC (Payload Based Classification) is made difficult by both obfuscation and cryptographic techniques such as AES and RSA algorithms [15], indeed, Skype flows that employ UDP must use SoM because of the possible packet reordering or dropping (UDP is unreliable!). Nonetheless, without this eventually SoM, encryption would make infeasible every PBC and moreover results of a PBC reach the best performance when it is used with complementary tools [14]. All these reasons led us to address towards the third category of identification methods, the Constraint-Based ones, and in particular toward the stochastic identification. 22

9 3.Statistical Types of Identification 3. Statistical Types of Identification T hese methods belong to the third category depicted in Figure 1 (pag.17): the Constraint-based methods. This is actually a subcategory of session-based identification but what characterizes these methods is that they borrow concepts generally used in the area of statistics and normally do not require any application-level protocol information [4]. 3.1 Previous Works The idea of using the statistical properties of network traffic to classify flows, or at least to describe their behaviour is not new. Pioneering studies by Paxson et al. on Internet traffic characterization ([17] and [18]) focus on the relationship between observed statistical properties of flows and the application protocols that generated them. These papers, although show that analytical models describing random variables can be suitable to express the behaviour of a few protocols, however, don t make any attempt to classify flows according to application layer protocols. This goal is reached by Mena et al. [19] who showed how Real Audio flows may be identified among aggregates through a simple analysis of packet lengths and inter-arrival times. A similar approach has been used in [29] to analyze chat traffic. Stem- 23

10 3.Statistical Types of Identification ming from the observation that this kind of traffic is dominated by human interactions, this work proved the feasibility of identifying chat flows, whether or not they are using their own transport protocol or are layered on top of other application protocols like HTTP. To overcome one of the key issues with statistically trained classifiers, i.e. the lack of verifiable reference data, this work was based on the statistical analysis of Internet Relay Chat traffic traces, since such traffic flows are easily identifiable even by payload analysis. This work, however, focuses exclusively on a single class of applications. Other approaches (see [22]) confirm the possibility of discrimination between different application classes with the objective of supporting service differentiation. A recent work of Bernaille et al. [20] proposes the use of clustering techniques to achieve fine-grained classification based on size and direction of packets, in [21] Nilsson et al. focuses on the statistical analysis of network traffic too, and shows promising results for fine-grained protocol classification. 24