Network Address Translation (NAT) Behaviour: Final report

Transcription

1 Network Address Translation (NAT) Behaviour: Final report Prepared by: A. Nur Zincir-Heywood Yasemin Gokcen Vahid Aghaevi Faculty of Computer Science Dalhousie University Scientific Authority: Rodney Howes DRDC Centre for Security Science The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada. Defence R&D Canada Centre for Security Science DRDC-RDDC-2014-C May 2014

2 IMPORTANT INFORMATIVE STATEMENTS CSSP-2012-CD-1029 Network Address Translation (NAT) Behaviour was supported by the Canadian Safety and Security Program (CSSP) which is led by Defence Research and Development Canada s Centre for Security Science, in partnership with Public Safety Canada. Partners in the project include Public Safety Canada and Dalhousie University. CSSP is a federally-funded program to strengthen Canada s ability to anticipate, prevent/mitigate, prepare for, respond to, and recover from natural disasters, serious accidents, crime and terrorism through the convergence of science and technology with policy, operations and intelligence Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2014 Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2014

3 Network Address Translation (NAT) Behaviour: Final report Contract Number: Project Leader: Graduate Students: A. Nur Zincir-Heywood Yasemin Gokcen Vahid Aghaevi Date:March 28 th, 2013 Network Information Management and Security Group Faculty of Computer Science Dalhousie University 6050 University Avenue Halifax, NS B3H 1W5

4 Contents Table of Figures and Tables... 3 Acronyms... 4 Abstract Introduction Literature Review NAT Overview Translation of the Endpoint Visibility of NAT Operations Data Mining Techniques Employed C Naive Bayes Support Vector Machine (SVM) Methodology and Evaluation Data Sets Employed Passive Fingerprinting Approach Packet Header Based Features - Time to Live (TTL) and Arrival Time Packet Payload Based Features - Http User Agent String Data Mining Based Approach No Payload, IP Addresses and Port Numbers Flow Based Features Ground Truth Labeling of the Data Sets Empirical Evaluation Evaluation Results Based On The First Labeling Scheme Evaluation Results Based On The Second Labeling Scheme Conclusion and Future Work References:

5 Table of Figures and Tables Figure 1 NAT trace collection scenario Figure 2: Home-Side trace: Consider the Source IP/Port and Destination IP/Port for the HTTP GET and the 200 OK HTTP messages Figure 3 Home-Side trace: Consider the Source IP/Port and Destination IP/port for the three-way SYN/ACK handshake Figure 4 ISP-Side trace: Consider the Source IP/Port and Destination IP/port for the HTTP GET and the 200 OK HTTP messages Figure 5 Home-Side trace: Consider the Time To Live and Checksum fields for HTTP GET message Figure 6 ISP-Side trace: Consider the Time To Live and Checksum fields for HTTP GET message Figure 7 ISP-Side trace: Consider the Source IP/Port and Destination IP/port for the three-way SYN/ACK handshake Figure 8: Construction of a classification tree Figure 9: An example of Naive Bayes Figure 10: Maximum margin hyperplanes for a SVM trained with samples from two classes Figure 11: Propagation Behavior of TTL between IP Header and MPLS Labels Table 1 Packet Header based features employed, * Normalized by log 37 Table 2: Packet Header based features employed, * Normalized by log Table 3: Packet Header based features employed, * Normalized by log Table 4: Packet Header based features employed, * Normalized by log Table 5: Flow Based Features Employed Table 6: Results for the flow-based feature set using the passive fingerprinting approach Labeling Scheme Table 7: Training Results for the flow-based feature set using the data mining approach Labeling Scheme Table 8: Test Results on the unseen dataset for the flow-based feature set using the data mining approach Labeling Scheme Table 9: Results for the flow-based feature set using the passive fingerprinting approach Labeling Scheme Table 10: Training Results for the flow-based feature set using the data mining approach Labeling Scheme Table 11: Test Results on the unseen dataset for the flow-based feature set using the data mining approach Labeling Scheme

6 Acronyms ACK Acknowledge Dal Dalhousie University DNS Domain Name Server DPI Deep Packet Inspection DR Detection Rate DSL Digital Subscriber Line eaddr External Address eport External Port FN False Negative FP False Positive FPR False Positive Rate FTP File Transfer Protocol HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure iaddr Internal Address ID3 Iterative Dichotomiser 3 IP Internet Protocol iport Internal Port ISP Internet Service Provider LAN Local Area Network NAPT Network Address and Port Translation NAT Network Address Translation OS Operating System PC Personal Computer QoS Quality of Service RFC 1918 A standard; Address Allocation for Private Internets RFC 2663 A standard; IP Network Address Translator (NAT) Terminology and Considerations 4

7 ROC SRM SVM SYN TCP TN TP TTL UDP WiFi Receiver Operating Characteristic Structural Risk Minimization Support Vector Machine Synchronize Transmission Control Protocol True Negative True Positive Time to Live User Datagram Protocol Wireless Fidelity 5

8 Abstract Network Address Translation (NAT) is the mechanism, which is used to modify a packet's IP address information while it is in transit across a network routing device. Because NAT can hide a computer s or even a network's IP address, identifying the presence of NAT in network traffic is an important task for network management and security. The aim of this work is to identify the presence of NAT in the network traffic by utilizing different approaches and evaluate the performance of these approaches under different network environments represented by the availability of different data fields. To this end, passive fingerprinting and data mining based approaches are used and evaluated under different test conditions. In these experiments, not only packet header and flow based features are employed without using source and destination IP addresses, source and destination port numbers and payload information, but also payload information is analyzed to understand how much performance gain is reached if it is available. Last but not least; experiments are also performed to identify NAT devices in encrypted as well as non-encrypted traffic. 6

9 1. Introduction Usage of Network Address Translation (NAT) devices is very common in any area where interconnection devices such as computers, laptops and mobiles connect to the Internet. While NAT devices are generally used in local area networks (LAN), which include small groups of computers, they can also be used just for one computer. In home networks most Internet Service Providers (ISP) give WiFi-enabled NAT home gateways to their users. Thus, when users can connect their devices to the Internet, the private IP addresses are hidden on the Internet by encapsulating private IP addresses with a public IP address. NAT gateways modify IP address information in IP packet headers during transition. Basically, NAT allows a single device, such as a router, to act as agent between the Internet and a private network. This means that only a single unique IP address is required to represent an entire group of computers to anything outside their private network. NATs are used for many reasons such as shortage of IPv4 addresses. Since an address is 4 bytes, the total number of available addresses is 2 to the power of 32, i.e. 4,294,967,296. This represents the number of computers that can be directly connected to the Internet. In practice, the real limit is much smaller for several reasons. Each physical network has to have a unique Network Number comprising some of the bits of the IP address. The rest of the bits are used as a Host Number to uniquely identify each computer on that network. The number of unique Network Numbers that can be assigned on the Internet is therefore much smaller than 4 billion, and it is very unlikely that all of the possible Host Numbers in each Network Number are fully assigned. NAT usage provides one single public IP address for a group of computers and therefore helps to solve some of the addressing related problems. 7

10 To be represented with a public IP address on the Internet is more advantageous for users. Since their private IP addresses are not seen on the Internet, it is easier for them to keep their systems secure. For home users, personal information, such as s, financial details such as credit cards or cheque numbers can be stolen. For business users, it is more dangerous. There is essential company information such as marketing strategies. If these kinds of essential information are stolen or accessed in any way, this may cause major privacy and security problems. For these reasons, companies can use firewall technologies to keep their systems safe. Firewalls are placed between the user and the Internet and verify all traffic before allowing it to pass through so no unauthorized user would be allowed to access the company's file or server. The problem with firewall solutions is that they are expensive and difficult to set up and maintain for home and small business users. In this case, NAT becomes a viable alternative. A NAT device is also placed between the user and the Internet and it automatically protects the systems without any special set-up because it only allows connections that are originated on the inside network. For instance, an internal client can connect to an outside FTP server, but an outside client will not be able to connect to an internal FTP server because it would have to originate the connection, and NAT will not allow that. It is still possible to make some internal servers available to the outside world by opening inbound ports, which are well known Transmission Control Protocol (TCP) ports (e.g. 21 for FTP) to specific internal addresses, thus making services such as FTP or Web available in a controlled way. Moreover, it is easier to manage the large networks for network administrators if there are NATs. That is because a NAT divides large networks into smaller ones. There are groups of computers behind NAT devices. While there are many computers, they are represented as one IP 8

11 address to the outside. Therefore, if any change happens within these groups, such as adding or removing IP addresses, this does not affect the outside network. All these advantages promote NAT usage. However, because of these reasons, NAT technology also becomes useful for attackers and users who want to hide their real identities. Hence, NAT usage increases both in legitimate environments and in illegitimate environments. Thus, it becomes important to detect the number of devices behind a NAT gateway in order to understand the anomalies in a given systems traffic and usage. Furthermore, it is not possible to get information such as private IP addresses, which belong to the devices behind a NAT gateway just by visualizing the traffic. In other words, identifying the NAT machines and the devices behind such machine becomes a very challenging problem. A NAT gateway has at least two interfaces and it has two different IP addresses for these two interfaces; namely internal and external IP addresses. The internal IP address is for communicating with hosts behind the NAT, while the external one is for communicating with the outside network. Therefore, if anyone from outside of this network wants to analyze the network traffic, the only information he/she will see will be the traffic between the NAT and the outside networks rather than the hosts behind the NAT on the internal network. On the internal network, there might be many devices, which are connected to the Internet behind the NAT and these devices might have different services installed. However, these will all be opaque when standard techniques (such as IP address or port number analysis or deep packet inspection) are used to visualize or analyze such traffic (data).thus, it is necessary both to understand whether there is a NAT gateway and to determine the number of hosts behind it to support any quality of service or security related analysis of a network/system traffic. 9

12 Therefore in this research, we study and evaluate different approaches and evaluate them on different types of data sets to understand their pros and cons. To this end, one approach we investigated was based on the analysis of packet level traces and HTTP user agent information as studied in [2]. Indeed, such an approach becomes useful in the presence of HTTP user agent information. So in the cases where such information is not available or not accessible, we also analyzed the flow level traffic using data mining techniques. We investigated all these approaches under both encrypted and non-encrypted traffic conditions. 10

13 2. Literature Review Even though not many, there are some works in the literature where the focus was on the identification of NAT gateways and the number of end users behind such gateways. Different algorithms were proposed, but generally, researchers used passive operating system fingerprinting by analyzing certain parameters within the TCP protocol and evaluated performances in their experimental system with synthetic NAT data sets. Bellovin [8] claimed that consecutive packets carry sequential IP ID fields, which are included in the IP header and generally are used as counters. Therefore, he claimed that it was possible to count the string values of those IP ID fields to find the number of hosts. However, he noted that there might have been some complications such as packets with zero IP IDs and packets using byte-swapped counters. Also, he did not take the recent version of OpenBSD and FreeBSD into consideration, because they use pseudo-random number generator for the IP ID fields. He proposed an algorithm and tested with a synthetic NAT data. Miller [6] and Phaal [5] both used passive OS fingerprinting. Phaal [5] took the advantage of IP Time to live (TTL), while Miller [6] analyzed TCP dump packets to check certain fields in the TCP/IP header. Beverly [7] proposed a classifier to infer the operating system passively and find the number of hosts behind a NAT. He used TTL, Do not fragment (DF), Window size and SYN size parameters. He also took the advantage of Bellovin's IP ID approach. According to the results of his evaluations, Bellovin's method performed better on counting hosts behind NAT devices. On the other hand, Murakami et al. [3] focused on the Medium Access Control (MAC) address of a device and proposed a NAT router, which relays the MAC address of PCs based on FreeBSD. NAT does not have information about the data link layer because it translates IP 11

14 addresses in the network layer. So they used two functions; obtaining source MAC address and overwriting an Ethernet header. They added another mechanism by using pcap both to obtain MAC addresses and to overwrite ethernet headers. According to their evaluation process, their MAC address relaying NAT router confirmed that a LAN could identify PCs that are behind a NAT from outside. However, it requires the use of their specific relaying system. Ishikava et al. [1] proposed an alternate method to identify PCs behind a NAT router with proxy authentication on a proxy server. Their target application was WWW. They used the realm attribute in the authentication header for identifying client PCs using their MAC addresses. In this case, the realm attribute is shown to the user as a prompt message. Therefore their proposed system requires Java Runtime Environment (JRE) on each client PC. They assumed that a web browser always adds the authentication header to its request message when authentication has succeeded. Rui et al. [4] proposed an algorithm based on the Support Vector Machine (SVM) learning algorithm just to detect the presence of a NAT. Their traces were limited by eight features and activity values (activeness of a host). They labeled their traffic data as ordinary hosts and hosts behind a NAT. Then, they applied binary classification. Maier et al. [2] focused on detecting DSL lines that use NAT to connect to the Internet. They first aimed to find whether there was a NAT device, and then they aimed to find the number of users behind that NAT. Additionally, they tried to find how many of those users connected to the Internet at the same time. Their approach is based on IP TTL and HTTP user agent strings. They extract the operating system and the browser family and versions from HTTP user agent strings. Indeed, this necessitates deep packet inspection (DPI) into the payload of a packet. They analyzed the user agent strings just from typical browsers and they ignored the ones 12

15 which came from mobile devices and gaming consoles. They employed two approaches to predict the minimum number of users behind a NAT. In the first approach, they counted different <TTL, OS> combinations as distinct hosts. In the second approach, for each <TTL, OS> combination, they counted the number of different browser versions of the same browser family as distinct hosts. They did not consider each different browser family as a distinct host. They found 10% of DSL lines have more than one user active at the same time, and that 20% of the lines have multiple hosts that are active within one hour of each other. 13

16 In summary, in our research, we reengineered the approach in [2], which seems to be the best technique in the literature notwithstanding its requirement for payload information, to understand its pros and cons better. In addition, for the cases where payload information not available or opaque (such as encrypted traffic), we use flow based attributes via a classification system in order to study whether one can learn general enough patterns to represent the behavior of NAT devices in a given network/system under analysis. In this second approach we employed, we are in some way similar to the work in [4]. However, we employ flow features rather than packet features and we aim to understand NAT behavior to identify its presence in a given traffic trace and the number of hosts behind such a NAT device. 14

17 3. NAT Overview In computer networking, network address translation (NAT) is the process of modifying IP address information in IP packet headers while in transit across a traffic routing device. It is common to hide an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another (usually public) address space. To avoid ambiguity in the handling of returned packets, a one-to-many NAT must alter higher-level information such as TCP/UDP ports in outgoing communications and must maintain a translation table so that return packets can be correctly translated back. RFC 2663 uses the term NAPT (network address and port translation) for this type of NAT. Since this is the most common type of NAT, it is often referred to simply as NAT. The majority of NATs map multiple private hosts to one publicly exposed IP address. In a typical configuration, a local network uses one of the designated "private" IP address subnets (RFC 1918) [24]. A router on that network has a private address in that address space. The router is also connected to the Internet with a "public" address assigned by an ISP. As traffic passes from the local network to the Internet, the source address in each packet is translated on the fly from a private address to the public address. The router tracks basic data about each active connection (particularly the destination address and port). When a reply returns to the router, it uses the connection tracking data that it stored during the outbound phase to determine the private address on the internal network to which to forward the packet. All Internet packets have a source IP address and a destination IP address. Typically packets passing from the private network to the public network will have their source addresses modified while packets passing from the public network back to the private network will have their destination addresses modified. To avoid ambiguity in how to translate returned packets, 15

18 further modifications to the packets are required. The vast bulk of Internet traffic is TCP and UDP packets, and for these protocols the port numbers are changed so that the combination of IP and port information on the returned packet can be unambiguously mapped to the corresponding private address and port information. Once an internal address (iaddr:iport) is mapped to an external address (eaddr:eport), any packets from iaddr:iport will be sent through eaddr:eport. Any external host can send packets to iaddr:iport by sending packets to eaddr:eport. For the purpose of this research, first of all, we observed the behavior of the NAT protocol in practice. In this case, we captured packets at both the input and the output sides of an NAT device. To this end, we sent and captured packets from a client PC (at a home network) to the web server at our faculty, namely Within the home network, the home network router provides a NAT service. Figure 1 shows our Wireshark trace-collection scenario. We have collected a Wireshark trace on the client PC in our home network. We call it the Home_Side trace. Because we are also interested in the packets being sent by the NAT router into the ISP, we have collected a second trace file at a PC on the ISP network, as shown in Figure 1. Client-toserver packets captured by Wireshark at this point will have undergone NAT translation. The Wireshark trace captured on the ISP side of the home router is called the ISP-Side trace. Figure 1 NAT trace collection scenario 16

19 3.1 Translation of the Endpoint NAT usage provides that all communication that are sent to external hosts actually contain the external IP address and port information of the NAT device instead of the internal host(s) IPs or port numbers. Figure 2 shows that the HTTP GET sent from the client to the faculty server (whose IP address is ) at time Figure 2: Home-Side trace: Consider the Source IP/Port and Destination IP/Port for the HTTP GET and the 200 OK HTTP messages The following are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP GET request. Source IP: , Source Port: 1268 Destination IP: , Destination Port: 80 17

20 At time , the corresponding 200 OK HTTP message received from the faculty server. The following are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP 200 OK message. Source IP: , Source Port: 80 Destination IP: , Destination Port: 1268 Recall that before a GET command can be sent to an HTTP server, TCP must first set up a connection using the three-way SYN/ACK handshake. Considering Figure 3, you can find the following information for SYN and ACK messages: SYN Time: SYN Source IP: , Source Port: 1268 SYN Destination IP: , Destination Port: 80 ACK Time: ACK Source IP: , Source Port: 80 ACK Destination IP: , Destination Port:

21 Figure 3 Home-Side trace: Consider the Source IP/Port and Destination IP/port for the three-way SYN/ACK handshake In the following, we will focus on the two HTTP messages (GET and 200 OK) and the TCP SYN and ACK segments identified above in the ISP-Side trace captured on the ISP network. Because these captured frames have already been forwarded through the NAT router, we are going to show that some of the IP addresses and port numbers have been changed as a result of the NAT translation. Note that the time stamps in ISP-Side and Home-Side traces are not synchronized since the packet captures at the two locations shown in Figure 1 were not started simultaneously. (Indeed, you can find that the timestamps of a packet captured at the ISP network is actually bigger than the timestamp of the packet captured at the client PC). Consider Figure 4, the NAT ISP-Side trace. The HTTP GET message has been sent from the client to the faculty server at time The source and the destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP GET are as the following: Source IP: , Source Port:

22 Destination IP: , Destination Port: 80 As you can see, in comparison to Figure 2, the destination IP and port have not been changed, but the source IP and port have been translated by the NAT router. Figure 4 ISP-Side trace: Consider the Source IP/Port and Destination IP/port for the HTTP GET and the 200 OK HTTP messages Our observations show that when a computer on the private (internal) network sends a packet to the external network, the NAT device replaces the internal IP address in the source field of the packet header (sender's address) with the external IP address of the NAT device. NAT may then assign the connection a port number from a pool of available ports, inserting this port number in the source port field (much like the post office box number), and forwards the packet to the external network. The NAT device then makes an entry in a translation table containing the internal IP address, original source port, and the translated source port. Subsequent packets from the same connection are translated to the same port number. The computer receiving a packet that has undergone the NAT device translation establishes a 20

23 connection to the port and IP address specified in the altered packet, oblivious to the fact that the supplied address is being translated (analogous to using a post office box number). A packet coming from the external network is mapped to a corresponding internal IP address and the port number from the translation table, replacing the external IP address and the port number in the incoming packet header. The packet is then forwarded over the inside network. Otherwise, if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the NAT device does not know where to send it. Most importantly, in addition to the IP address and the Port fields, two more fields in the IP datagram have also been changed, Time to Live (TTL) and Checksum. Consider Figure 5 and Figure 6 to compare the TTL and Checksum fields of the HTTP GET message in the Home-Side and the ISP-Side traces. Figure 5 Home-Side trace: Consider the Time To Live and Checksum fields for HTTP GET message 21

24 Figure 6 ISP-Side trace: Consider the Time To Live and Checksum fields for HTTP GET message The TTL value can be thought of as an upper bound on the time that an IP datagram can exist in an Internet system. The TTL field is set by the sender of the datagram, and reduced by every router on the route to its destination. The purpose of the TTL field is to avoid a situation in which an undeliverable datagram keeps circulating on an Internet system, and such a system eventually becoming swamped by such immortals". Under IPv4, every host that passes the datagram must reduce the TTL by one unit. In practice, the TTL field is reduced by one at every hop (router/gateway), including NAT devices (most of the time). In this case, we have also observed that the TTL has been decreased by one in figure 6. It should be noted here that it is possible to configure the NAT device, as well as every other network device, to not to decrease the TTL value. Regarding the checksum value, the major transport layer protocols, TCP and UDP, have a checksum that covers all the data they carry, as well as the TCP/UDP header, plus a "pseudoheader" that contains the source and destination IP addresses of the packet carrying the 22

25 TCP/UDP header. For an originating NAT to pass TCP or UDP successfully, it must re-compute the TCP/UDP header checksum based on the translated IP addresses, not the original ones, and put that checksum into the TCP/UDP header of the first packet of the fragmented set of packets. The receiving NAT must re-compute the IP checksum on every packet it passes to the destination host, and also recognize and re-compute the TCP/UDP header using the retranslated addresses. In the ISP-Side trace file, Figure 7, you can find the following information for the three-way SYN/ACK handshake: SYN Time: SYN Source IP: , Source Port: SYN Destination IP: , Destination Port: 80 ACK Time: ACK Source IP: , Source Port: 80 ACK Destination IP: , Destination Port: Comparing figure 7 and figure 3, you can see that the source IP and the port in the ACK message (direction from the home side to the ISP side) and destination IP and the port in the SYN message (direction from the ISP side to the home side) have been translated by the NAT router. 23

26 Figure 7 ISP-Side trace: Consider the Source IP/Port and Destination IP/port for the three-way SYN/ACK handshake 3.2 Visibility of NAT Operations Typically the internal host is aware of the true IP address and the TCP/UDP port of the external host. The NAT device may function as the default gateway for the internal host. However, the external host is only aware of the public IP address for the NAT device and the particular port being used to communicate on behalf of a specific internal host. As discussed above, NAT only translates the IP addresses and ports of its internal hosts, possibly decreasing the TTL value by one, and re-computing the checksum. This results in translating the IP addresses and ports of its internal hosts to hide the true endpoint of an internal host on a private network. Because the internal addresses are all disguised behind one publicly accessible address, it is impossible for the external hosts to differentiate between the traffic originated from a network behind a NAT and one that did not. As a result, these networks are 24

27 ideal for attackers to hide their identities. If an attacker hides his/her identity behind a NAT device, it is very difficult to find the exact attacker node. Thus, a mechanism of identifying the NAT traffic is needed, as the attackers behind the NAT devices can easily violate the network security. This is the main purpose of this study. However achieving this purpose is not possible by using the typical network traffic analysis techniques, because NAT only translates the IP addresses and ports of its internal hosts, possibly decreasing the TTL value, and re-computing the checksum. In short, we use a combination of techniques including machine learning (data mining) algorithms to achieve this goal. 25

28 4. Data Mining Techniques Employed In this research, we have employed a data mining (machine learning) based approach to find whether a NAT box exists in a network or not. To this end, we have employed a decision tree system, e.g. C4.5, a function system, namely Support Vector Machine (SVM), and a probabilistic system, namely Naive Bayes. The following will summarize all these techniques. 4.1 C4.5 C4.5 is a decision tree based classification algorithm developed by Ross Quinlan that is an extension of the basic ID3 algorithm [9]. C4.5 is designed to address issues that are not dealt with in ID3 such as choosing the appropriate attribute (based on information gain), trying to reduce error pruning, and handling varieties of attributes types (continuous, number, string). A decision tree is a hierarchical data structure for implementing a divide-and-conquer strategy. C4.5 is an efficient non-parametric method that can be used to support both classification and regression. In non-parametric models, C4.5 constructs decision trees from a set of training data applying the concept of information entropy. The training data is a set, S, such that each input of the set is an instance of already classified samples. Each sample (record) in the set is represented as a vector and each input in the vector is represented as an attribute (feature) of the sample. The training data is added to a vector where each input in the vector represents a class that each sample belongs to. C4.5 can split the data into smaller subsets using the fact that each attribute of the data can be used to make a decision. Therefore, the attribute with highest information gain is used to make the decision of the split. As a result, the input space is divided into local regions defined by a distance metric. In a decision tree, the local region is identified in a sequence of recursive splits in small number of steps. A decision tree is composed of internal 26

29 decision nodes and terminal leaves. Each node, m, implements a test function f m (x) with discrete outcomes labeling the branches. This process starts at the root and is repeated until a leaf node is hit. The value of a leaf node constitutes the output. In the case of a decision tree for classification, the goodness of a split is quantified by an impurity measure. A split is pure if, for all branches, for all instances, choosing a branch belongs to the same class after the split. One possible function to measure impurity is entropy, Eq. (1) [10]. = log (1) If the split is not pure, then the instances should be split to decrease impurity, and there are multiple possible attributes on which a split can be done. Indeed, this is locally optimal; hence, there is no guarantee of finding the smallest decision tree. In this case, the total impurity after the split can be measured by Eq. (2) [10]. In other words, when a tree is constructed, at each step the split that results in the largest decrease in impurity is chosen. This is the difference between the impurity of data reaching node m, Eq. (1), and the total entropy of data reaching its branches after the split, Eq. (2). Figure 8 presents the construction of a classification tree. A more detailed explanation of C4.5 algorithm can be found in [10]. = (2) 27

30 Figure 8: Construction of a classification tree 4.2 Naive Bayes A Naive Bayes classifier is a simple probabilistic classifier based on applying Bayes' theorem (from Bayesian statistics) with strong (naive) independence assumptions. In simple terms, a naive Bayes classifier assumes that the presence (or absence) of a particular feature of a class is unrelated to the presence (or absence) of any other feature. Depending on the precise nature of the probability model, Naive Bayes classifiers can be trained efficiently in a supervised learning approach. In many practical applications, parameter estimation for Naive Bayes models uses the method of maximum likelihood [11]. A simple Naive Bayes probabilistic model can be expressed as Eq. (3) in the following: (,,, ) = ( ) ( ), (3) 28

31 where (,,, ) is the probabilistic model over dependent class variable C with a small number of outcomes or classes, conditional on several feature variables F 1 through F n ; Z is a scaling factor dependent only on,,,, i.e., a constant if the value of the feature variables are known. A Naive Bayes classifier combines the probabilistic model with a decision rule that aims to maximize a posterior, thus the classifier can be defined using Eq. (4) as follows: (,,., ) = ( = ) ( = = ) (4) An advantage of the naive Bayes classifier is that it only requires a small amount of training data to estimate the parameters (means and variances of the variables) necessary for classification. Because independent variables are assumed, only the variances of the variables for each class need to be determined and not the entire covariance matrix. Figure 9: An example of Naive Bayes Figure 9 shows an example of Naive Bayes. Naive Bayes is the simplest form of Bayesian network. All attributes are independent given the value of class variable. This is called conditional independence. The conditional independence assumption is not often true in the real world problems. The authors of [12] aimed to show that the Naive Bayes classifier might have been successful to choose who would reply to the mailing for the 1998 KDD Data cup. They evaluated their tests and explained time and space complexities of Naive Bayes by drawing graphs. Time complexity for learning a Naive Bayes classifier is O(Np), where N is the number 29

32 of training examples and p is the number of features. Space complexity for Naive Bayes algorithm is O(pqr), where p is the number of features, q is values for each feature, and r is alternative values for the class. 4.3 Support Vector Machine (SVM) The original SVM algorithm was invented by Vladimir N. Vapnik and the current standard incarnation (soft margin) was proposed by Vapnik and Corinna Cortes in 1995 [15]. Classifying data is a common task in machine learning. Suppose some given data points each belong to one of two classes, and the goal is to decide which class a new data point will be in. In the case of support vector machines, a data point is viewed as a p-dimensional vector (a list of p numbers), and we want to know whether we can separate such points with a (p 1) dimensional hyperplane. This is called a linear classifier. There are many hyperplanes that might classify the data. One reasonable choice as the best hyperplane is the one that represents the largest separation, or margin, between the two classes. So we choose the hyperplane so that the distance from it to the nearest data point on each side is maximized. If such a hyperplane exists, it is known as the maximum-margin hyperplane and the linear classifier it defines is known as a maximum margin classifier; or equivalently, the perceptron of optimal stability [13] We consider data points of the form as follows: {(, ), (, ), (, ), (, ),,(, )}, (5) Where = 1/-1, a constant denoting the class to which that point belongs and n is the number of samples. Each is p-dimensional real vector. The scaling is important to guard against variable (attribute) with larger variance. We can view this training data, by means of dividing hyperplane, which takes 30

33 w.x + b = 0, (6) where b is scalar and w is p=dimensional vector. The vector w points perpendicular to the separating hyperplane. Adding the offset parameter b allows to increase the margin. Absent of b, the hyperplane is forced to pass through the origin, restricting the solution. As we are interesting in the maximum margin, we are interested SVM and the parallel hyperplanes. Parallel hyperplanes can be described by the Eq. (7) in [13]: w.x + b = 1 w.x + b = -1 (7) A special property of SVM is that SVM simultaneously minimizes the empirical classification error and maximizes the geometric margin. So SVM can be considered as a Maximum Margin Classifier. SVM is based on the Structural Risk Minimization (SRM). SVM maps an input vector to a higher dimensional space where a maximally separating hyperplane is constructed. Two parallel hyperplanes are constructed on each side of the hyperplane that separate the data. The separating hyperplane is the hyperplane that maximize the distance between the two parallel hyperplanes. An assumption is made that the larger the margin or distance between these parallel hyperplanes the better the generalization error of the classifier will be [14]. 31

34 Figure 10: Maximum margin hyperplanes for a SVM trained with samples from two classes 32

35 5. Methodology and Evaluation As discussed earlier, in this work, we considered and evaluated two different approaches, namely a data mining approach and a passive operating system fingerprinting by analyzing specific parameters within the TCP protocol. For the data mining approach, we employed the classification models, C4.5, Naïve Bayes and SVM learning techniques introduced in section 4. As for the passive fingerprinting approach, we re-engineer and employ the algorithm introduced by Maier et al. [2]. For both approaches we used exactly the same data sets including both the encrypted and the non-encrypted traffic. In doing so, we aim to understand the behavior of NAT both with and without the payload information. Moreover, for the first approach, we analyzed the used of both the packet only and the flow only features to detect the presence of NAT devices. The following describes the data sets and experiments performed in this work. 5.1 Data Sets Employed In this research, we employed traffic data sets from our faculty s web server in the form of TCP dump files, which did not have any payload, as well as the corresponding web server access log files, which have the payload. The data was collected over a week in November 2012 and data sets have both encrypted and non-encrypted traffic. In total, there are flows in our dataset. All these flows were matched with the web access log data files which are encrypted (HTTPS) and non-encrypted (HTTP). We divided (detailed in section 5.4) these flows into two categories: (i) NAT flows; and (ii) OTHER flows. However, some flows did not have valid user agent strings. This means that some user agent strings did not include OS information and some of them did not include browser related information. We consider the flows that have these types of user agents in the OTHER category. 33

36 In the whole dataset, 95 different OSs and 105 different browser families with their versions exist. Furthermore we know that in our own faculty we have a NAT device for some of the labs. Indeed, computers from these labs (behind the NAT device) access the web server (where we collected the data sets). Thus, the choice of these data sets enables us to derive some ground truth information about the presence of NAT devices in the data sets, too. 5.2 Passive Fingerprinting Approach In this case, we first introduced the features used in the passive fingerprinting approach that we adopted from Maier et al. [2] and re-engineered to use in our work. In applying this approach certain features are used to identify a NAT device. Some of these features require the payload to be known otherwise they cannot be extracted from the data set. Other features do not have that requirement. We detail these features below Packet Header Based Features - Time to Live (TTL) and Arrival Time It is known that networking stacks of operating systems use well-defined initial IP TTL values (ttl init ) in outgoing packets. For instance, Windows uses 128, MacOS uses 64 and Debian based systems use 64, too. The TTL field of the IP header is defined to be a timer limiting the lifetime of a datagram. It is an 8-bit field and the units are in seconds. Each router (or other modules) that handles a packet must decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, in effect, the TTL values serves as a hop count limit on how far a datagram can propagate through the Internet as it is shown in Figure 11 [18].When a router forwards a packet, it must reduce the TTL by at least one. If it holds a packet for more than one second, it may decrement the TTL by one for each second. 34

37 Therefore, it is expected that if there is a NAT box routing in the network, it will decrement the TTL values for each packet that passes through them. However, it is possible for a NAT box not to decrement TTL values. Moreover, users could reconfigure their systems to use a different TTL. In this case, we cannot detect accurately whether there is a NAT box or not by solely relying on TTL counts. However, assuming that TTL values are not modified or hidden, these TTL values in the packets enable us to infer the presence of NAT. If the TTL is ttl init -1, this means that the sending host is directly connected to the Internet, so the monitoring point is one hop away from the host. If the TTL is ttl init -2 then there is a routing device such as a NAT gateway. A NAT gateway can be a dedicated gateway such as a home router or it can be a regular desktop or notebook. A dedicated NAT gateway will often directly interact with the Internet services, e.g., by serving as DNS resolver for the local network or for synchronizing its time with NTP servers. Moreover they generally do not use web (HTTP). It should be noted here that in our datasets we cannot see any DNS records originated by the known NAT devices. Figure 11: Propagation Behavior of TTL between IP Header and MPLS Labels 35

38 In addition to the TTL feature, arrival time feature is also used. The "Arrival Time" feature reflects the timestamp recorded by the station that captures the traffic when the packet arrives. The accuracy of this field is only as accurate as the time on the receiving station. Packet captures from Windows systems are only represented with accuracy in seconds. In this work, we use arrival times to match packets with access log data and flow based data. We will explain this process in more detail in section 5.3. In short, TTL and arrival time features embody the two features of the passive fingerprinting approach that do not require any payload information. In other words, no deep packet inspection is necessary to extract these features from the traffic Packet Payload Based Features - Http User Agent String The user agent string identifies the browser that the user uses to access the web. When a user visits a webpage, his/her browser sends the user-agent string to the server hosting the site that is visited. This string indicates, which browser the user is using, its version number, and details about the user s system, such as the operating system and its version. We parsed the HTTP log files (access log files of the web server) and analyzed the user agent strings. We extracted the OS and browser information from these strings to estimate a lower bound for the number of hosts behind a NAT gateway. Maier et al. [2] limited their analysis to user agent strings from typical browsers such as Firefox, Internet Explorer, Safari and Opera. However, we did not limit ourselves with the typical browsers, because in our data sets, we also observed many user agent strings from Android based devices, iphones and ipads. Therefore, we took them into consideration in our study, too. We will discuss this in more detail in the following sub-sections. 36

39 User Agent String - OS Only As we mentioned in section 5.2, it is possible to detect whether there is a NAT gateway or not by analyzing the TTL values (assuming TTL values are not modified). For instance, if the TTL value of a packet is 125, which belongs to a Windows system with an initial TTL of 128, we can say that this computer is behind a routing device such as a NAT gateway. Furthermore, in this case, in order to predict (calculate) the number of users behind a NAT, we need to utilize the OS information, which belongs to the hosts. Thus, we can use a heuristic as: Different <TTL, OS>combinations represent distinct hosts. Then, we can calculate the number of different combinations and use this number to predict the number of users behind a NAT. An example for this is shown in Table 1. In this example, this approach predicts a NAT device s presence with three users behind it. However, there might be many users using the same combination, too. In this approach, they will be counted as one. Table 1 Packet Header based features employed, * Normalized by log From Packet Header From HTTP User Agent TTL Proto OS Family Version 54 80/HTTP Intel Mac OS X 10.5 Firefox /HTTP Windows NT 5.1 Internet Explorer /HTTP Windows NT 5.1 Firefox /HTTP Windows NT 5.1 Firefox /HTTP Windows NT 6.0 Internet Explorer /HTTP Windows NT 6.0 Firefox User Agent String - OS and Browser Version In this case, in addition to the OS information, we can also extract and count the number of different browser versions to predict the number of users behind a NAT device. This time, we 37

40 use the following heuristic: it is assumed that if the OSs is the same and the browsers families are the same but the browser versions are different, then we can count these as two distinct hosts. The rationale for this is that it is not possible to install different versions of a browser family on the same computer. For example, in Table 1, TTL values are the same for each packet, while there are different OSs such as Windows NT 5.1,Windows NT 6.0 and Intel Mac OS X The packets with Windows NT 5.1 OSs employ browsers from the same family, Firefox. Their TTLs, OSs and browser families are the same. According to the previous approach, we could count these two packets as belonging to one host. However, if we take into consideration the version of the browsers, then the conclusion could be different. In this example, they use different Firefox versions, so that means using our heuristic above, we can conclude that these packets belong to two distinct hosts. In summary in table 1, if we take all combinations into consideration there are three Windows NT 5.1 OSs with the same TTL value but two different browser families (types) and different versions. Two Windows NT 6.0 with the same TTL value have different browser families. This can mean two different users or one user with two different browsers. Finally, the packet with Intel Mac OS X 10.5 OS might be different host (user) or might be the same host (user) with dual OSs. In this case, we assume that two different versions of Windows OSs (NT 5.1 and NT 6.0) would not be installed on the same machine and the two different versions of the same browser would not be installed on the same machine either. Therefore, we count three hosts by analyzing these packets using our heuristics presented above. However, if TTL values were different, then we could say that those packets belong to different hosts. For instance, in Table 2 there are three hosts and in table 3, we count two distinct hosts. 38

41 Table 2: Packet Header based features employed, * Normalized by log From Packet Header From HTTP User Agent TTL Proto OS Family Version 56 80/HTTP Intel Mac OS X 10_8_2 Safari /HTTP Windows NT 6.2 Google Chrome /HTTP Windows NT 6.2 Google Chrome 22.0 Table 3: Packet Header based features employed, * Normalized by log From Packet Header From HTTP User Agent TTL Proto OS Family Version 56 80/HTTP Intel Mac OS X 10_7_5 Safari /HTTP Windows NT 6.1 Firefox /HTTP Windows NT 6.1 Internet Explorer 9.0 Table 4: Packet Header based features employed, * Normalized by log From Packet Header From HTTP User Agent TTL Proto OS Family Version 48 80/HTTP Android 2.2.x Froyo Safari /HTTP Android 2.0/1 Eclair Firefox /HTTP Windows NT 6.1 Internet Explorer 7.0 In this work, we also use the packets that belong to the Android and other mobile devices, while mobiles were not taken into consideration in previous works. In our data sets, we observed lots of records, which belonged to the mobile devices (in our network traces). There are many numbers of Android devices, iphone devices and ipad devices. When we analyze their user agent 39

42 strings, we can also see the device models; such as Nessus One and Samsung SGH-1896.As we show in Table 4, in this case, we count three different mobile hosts (users). 5.3 Data Mining Based Approach In this case, we will introduce the features applied in the data mining based approach. To this end, we have introduced the learning techniques that will be studied in section 4. In this approach, we only employ features (attributes) that are based on flow statistics. However, we do not use payload information, IP addresses and/or port numbers as features to this approach. The reasons behind this are as the following: One may not have access to payload information or the payload may be encrypted and therefore opaque. Moreover, IP addresses can be spoofed and ports numbers can be dynamically assigned. In short, such features can be biased. In some ways, one can say that NATs and proxies are already doing this for free. Thus, our aim here is to generate fingerprints (in other words signatures) automatically without using any biased features. We detail the features of this approach below No Payload, IP Addresses and Port Numbers Flow Based Features As a different approach, we converted our packet-based dataset to a flow-based dataset. To this end, NetMate [16] was employed to generate flows and compute features as shown in Table 5 below. Flows are bidirectional and the first packet seen by the tool determines the forward direction. We consider only UDP and TCP flows. UDP flows are terminated by a flow timeout, whereas TCP flows are terminated upon proper connection teardown or by a flow timeout, whichever occurs first. The flow timeout value employed in this work is 600 seconds as recommended by the IETF [17]. 40

43 5.4 Ground Truth Labeling of the Data Sets For evaluating the performance of each approach employed, we need to know actually how many NAT devices exists in our data sets so that we could measure the detection rate for each approach. We also need to know this information to be able to prepare training data sets for the data mining approach. In this research, we do not know every NAT device (from the Internet) that accesses the web server where we captured traffic. We only know for sure the ones (NAT devices) that are in our own faculty and access the web server. So we decided to label the data we captured using two different methods in order to see their effect on the performance: (i) Assuming the only NAT devices are the ones we know; and (ii) Assuming the number of NATs is more than the ones in (i) so predicting the number using the heuristics presented in the passive fingerprinting approach. These are detailed below Labeling Scheme-1 NAT Devices of the Faculty Only As discussed earlier, we use datasets, which were captured on our faculty s web server over a week in November In this case, NetMate as an open source tool is used to convert the packet-based data set into a flow-based data set. As our first ground truth, the IP Address of the faculty s NAT device is Therefore, the flows and packets with this IP address were all labeled as NAT. The remainder was labeled as OTHER (meaning non-nat). Hereafter, we will refer to those flows as NAT flows and OTHER flows. As a result of this labeling process, there are NAT flows among all the flows (out of a total flows) in the data set. It means that about 2.3% of our data set is NAT traffic based on this labeling scheme. Please note that for the data mining approach where we evaluated different learning techniques (C4.5, Naïve Bayes and SVM) to automatically 41

44 generate fingerprints, we removed the IP addresses and the port numbers (flows do not have payloads) from the flows Labeling Scheme-2 Potential NATs and Encrypted / Unencrypted Traffic In this case, even though we do not have any ground truth information regarding NAT devices other than the ones in our faculty, by using the fingerprints introduced in the first approach discussed earlier, we can potentially label more traffic as NAT, if they match to anyone of those fingerprints. Among our data sets we have not only TCP dump traffic collected on the web server but its corresponding web server access log files, too. To this end, we have two log files :(i) HTTP web access logs;(ii) HTTPS web access logs. The first one represents the non-encrypted and the second one represents the encrypted traffic. However, to be able to use this information, first we need to match the traffic logs (packet or flow) to the records in the access log files. Then we can label the flows without payload information accurately in terms of encrypted NAT or non-encrypted NAT traffic. To achieve this we checked the arrival time feature. Since we are dealing with the flows, we did not have arrival time feature for each flow, but we have it in packet-based access log files. Therefore we had to add time attribute to each flow in NetMate. After doing that modification, the time attributes of the flows were compared to the time attributes of the packets in HTTP and HTTPS files. As a result, we have 517 Encrypted-NAT flows among NAT flows. We can say Unencrypted-NAT for the rest NAT flows. Therefore, there are flows; 517 of them are Encrypted-NAT flows, of them are Unencrypted-NAT flows, of them non-nat flows, which are labeled as OTHER. 42

45 Table 5: Flow Based Features Employed 43